[Разработка, нужны советы] Компонент для УО (УК и тсж) - Расширения форумчан

Положено начало компонента для управляющих организаций (УО) в сфере ЖКХ таких как: управляющие компании (УК) и товарищества собственников жилья (ТСЖ).

Компонент можно взять здесь:
https://github.com/rsam/com_tsj

Компонент работает под Joomla 2.5. Под другими версиями не проверялся.
Пока это лишь бета-версия одной из функций задуманного компонента - ввод показаний индивидуальных счетчиков воды.

В директории DOC лежит UserManual с подробным описанием реализованной функции.
В версии 0.1.0 часть баз необходимо заполнять вручную. Это описано в UserManual.
Данную версию рекомендую использовать только для тестирований и ознакомительных целей. Рабочая версия будет носить номер 1.0.0 и появиться после исправления обнаруженных ошибок в бета-версии.

Об ошибках обнаруженных в компоненте можно сообщить на: https://github.com/rsam/com_tsj/issues

Код компонента далеко не совершенен. Это первый мой компонент, тем более выполненный с использованием MVC. Некоторые вещи сделаны не оптимально, некоторые кривовато по незнанию, некоторые интересно.
Буду признателен за замечания по коду (если кто захочет копаться в нем и указать на ошибки, недостатки и т.п.).

P.S.: Следующим этапом планирую дополнить компонент функцией заполнения дополнительный таблиц (тех что сейчас нужно заполнять вручную) через панель управления.

Хорошее начинание, очень не хватало такого компонента пару лет назад. Пришлось все через форму отправки сообщения делать. Удачи вам в разработке.

Супер. Давно не следил за темой. Ура, надо пробовать.
Правда не понял, поссылке раздельные файлы, может лучше слепить их в инсталятор единый?

Я сейчас уже сделал заполнение таблиц не в ручную через phpMyAdmin, а через панель управления. И сейчас допиливаю функцию экспорт из CSV файла. Думаю за новогодние каникулы допилю и выложу версию с этими фичами. Тогда можно будет уже использовать функцию ввода показаний счетчиков воды полноценно.
И архив, конечно тоже отдельно выложу.

а есть где демо посмотреть?

а есть где демо посмотреть?

Пока нет. Озадачен сейчас этим.

Я сейчас уже сделал заполнение таблиц не в ручную через phpMyAdmin, а через панель управления. И сейчас допиливаю функцию экспорт из CSV файла. Думаю за новогодние каникулы допилю и выложу версию с этими фичами. Тогда можно будет уже использовать функцию ввода показаний счетчиков воды полноценно.
И архив, конечно тоже отдельно выложу.

Ждёмс. Уже очень хочется функционала

Хорошая идея!
Буду следить и тестировать!

Выложил версию 1.0.0

https://github.com/rsam/com_tsj/tree/v1.0.0
Для закачки ZIP архива достаточно нажать кнопку ZIP (левее кнопки Clone in Windows)

- Добавлено заполнение таблиц через админ-панель.
- Добавлена функция импорта из CSV файла.
- Добавлена функция соглашения на использование личных данных пользователя на сайте. Текст соглашения можно менять - формат TXT
components\com_tsj\views\lic\tmpl\lic.txt

P.S.: В архиве в папке doc лежит также UserManual и пример CSV файла.

rsa_m баги по компоненту куда писать?

rsa_m баги по компоненту куда писать?

Лучше если на GIT
https://github.com/rsam/com_tsj/issues
Или на почту.
Или здесь в крайнем случае.

Хочу публично обсудить одну "проблему".

В моем компоненте есть функция импорта данных из CSV файла.
При этом, не вдаваясь в лишние подробности, автоматически добавляются зарегистрированные пользователи, т.е. вносятся записи в таблицу #_users Joomla.

И дело в том что мне не совсем нравиться как это сделано сейчас.
Может быть у форумчан есть идеи или наработанные решения, как лучше добавлять данные в таблицу users !?

Сейчас сделано так.
- логин пользователя получаем из поля CSV файла "лицевой счет" убирая пробелы и символы <>"'%;()&. Сейчас правда еще убираю и русские буквы - но это не нужно, исправлю.
Тут вроде все логично.

- пароль = логин
Здесь я заметил следующее. Сама таблица users, по-моему мнению достаточно странна. В нее можно добавить две абсолютно одинаковые записи с одинаковыми user, username, email и password!  В ней нет полей типа UNIQUE INDEX.

Надо сказать что регистрацию пользователей самостоятельно - я отмел с самого начала. Доступ к функциям компонента (т.е. логин и пароль), пользователь получает только через управляющую компанию (короче как в банке  ).

Вот тут возникает делема. При записи таблицы напрямую, пароль может состоять даже из одной цифры. Заметил что при добавлении пользователя через админ-панель стандартным способом мы должны ввести пароль не менее 6ти символом.
Так же при прямой записи в таблицу, пароль можно вообще не вводить. Однако в этом случае через стандартную форму "Login Form" войти не получиться, так как в ней поле password должно быть заполнено обязательно, иначе выдает ошибку.

Как лучше заполнять поле пароль?
Либо оставить как есть пароль=логин в начальный момент? Либо генерить к примеру 8 значный пароль и писать сгенеренные при импорте пароли в файл. А когда пользователь обращается в управляющую компанию - ему выдается логин и пароль из этого файла?

- email = <логин>@test.ru
Но поле при прямой записи в таблицу можно вообще не заполнять.
Снова замечу что при стандартном вводе пользователя через админ-панель, поле email обязательно для заполнения.

Как лучше сделать? Оставлять поле email не заполненным?
Тут нужно учесть что, так как в дальнейшем планируется сделать функцию просмотра истории платежей и т.п - а это личная информация, то функцию отправки пароля на email (если забыл) Я также отмел. По-моему мнению пароль в случае если его забыли, должен восстанавливаться только администратором сайта при обращении собственника в управляющую компанию.
И при таком подходе логично не генерить email автоматом.

Проблемка конечно та еще...

В свое время хотел делать подобное, правда для образовательного учреждения.
Правда делал для j1.5, допиливал под себя компонент User Loader, грузит пользователей из файла csv.

В итоге гемора куча.

Остановились на другом варианте, каждому пользователю выдается ключ из 10 символов (два в одном логин и пароль), по ниму в компоненте и определяется какие личные данные показывать. Так же делает например почта, вводите число - смотрите где ваш груз.

Может это более простое и удобное решение?

Прочитал ридми. Остался вопрос. Будет ли реализован показ "платежки" пользователю или что нибудь чтобы он смотрел сколько ему накапало за месяц? (в рублях)
Если да то готов частично финансово вложится в сей компонент.

Прочитал ридми. Остался вопрос. Будет ли реализован показ "платежки" пользователю или что нибудь чтобы он смотрел сколько ему накапало за месяц? (в рублях)

В планах такая функция в компоненте есть. Но в ней есть два больших вопроса, которые пока для меня остаются открытыми:
1. Для платежки, в некоторых случаях, нужна ежедневная связь с бухгалтерской программой.
Почему только в некоторых случаях!? Потому что тарифы устанавливаются на год и всегда заранее известны. Поэтому как правило платежку можно формировать исходя только из площади квартиры (или для некоторых статей из кол-ва зарегистрированных) и тарифов.
Но бывают случаи когда строка в платежке не может быть вычислена автоматом, например ежегодовой перерасчет за отопление и т.п. и т.д.
Но этот открытый вопрос можно решить достаточно просто. Пусть некий софт пишет в базу хоть каждый день любые цифры (долги, доп. статьи и т.д.), а задача функции компонента будет лишь отобразить это.

2. И тут приходим ко второму открытому вопросу. Чтобы отобразить, нужен некий конструктор платежек. Они ведь по внешнему виду могут различаться. Конечно есть некая "рекомендованная форма", но она же рекомендованная, а не обязательная. А сделать "конструктор платежек" задача не тривиальная. Но идеи есть.

Да... Но так как делал я то это просто геммор. Создавал вручную таблицу платежки, и каждый месяц сканил 250 квитанций и менял вручную через панель управления -)))
rsa_m
Но вы не ответили на мой второй вопрос... Финансовое вложение поможет разработке компонента?
Можно обсудить в аське.

Но вы не ответили на мой второй вопрос... Финансовое вложение поможет разработке компонента?

И да и нет.  Поясню.
Во-первых, не скрою, что и в самом компоненте и в документации есть ссылки на Webmoney и предложение о добровольном пожертвовании на развитие компонента.
Сей факт говорит о том что Я изначально предполагал саму возможность денежного стимулирования проекта. Но не в качестве платы "вперед", а в качестве того что если человек установит компонент и он ему понравиться, то он может простимулировать появление в компоненте новых функций. Другими словами, произведя пожертвование - скажет тем самым автору что его компонент интересен и должен развиваться далее.

Но с другой стороны, если под финансированием понимать классическую схему - плату за разработку определенной функции за определенный срок, то увы. Это мое хобби. И на данном этапе Я не хочу чтобы хобби перешло в Работу. А данная схема подразумевает под собой обязательства, что не совместимо с хобби. И второе, извините за самокритику, но Я еще очень и очень мало знаю Joomla, PHP и JavaScript чтобы браться за реализацию чего либо из этой области за деньги.

Но с другой стороны, если под финансированием понимать классическую схему - плату за разработку определенной функции за определенный срок, то увы. Это мое хобби. И на данном этапе Я не хочу чтобы хобби перешло в Работу. А данная схема подразумевает под собой обязательства, что не совместимо с хобби. И второе, извините за самокритику, но Я еще очень и очень мало знаю Joomla, PHP и JavaScript чтобы браться за реализацию чего либо из этой области за деньги.

Теперь поясню я. Если бы я хотел именно этой способ, прямой путь к фрилансерам. Мне понравился компонент и я хотел бы видеть его реализацию. А чтобы вы не подумали что этот компонент никому не интересен и не забросили его, был готов предоставить вам финансовую стимуляцию. Пусть и не такую, какой бы стоила реализация у фрилансера.
Но с другой стороны хотелось бы примерно представлять на какой срок реализации вы расчитываете?

Но с другой стороны хотелось бы примерно представлять на какой срок реализации вы расчитываете?

Я планирую исправить баги по части ввода показаний счетчиков воды - в течении 1 недели.
Затем 2 недели - прикрутить пару фич к тойже части по воде.
Затем 2 месяца - реализация подсистемы Тарифы. А подсистема Тарифы это в свою очередь одна из составляющих возможности просматривать и печатать свою платежку. Т.е. это та часть которая будет выводить тарифы УК или ТСЖ на сайт, а также эти тарифы (которые будут через админ-панель помещаться в базу, также как сейчас туда помещается адресная информация) будут использоваться в формировании платежки.

Остается открытым вопрос по формированию внешнего вида платежки. Не могу сейчас сказать сколько эта часть может занять точно, но ориентироваться нужно на 1.2 - 2 месяца.
Но общая идея по "генератору визуального представления платежки" такая, что не нужно городить мега визуальный генератор, которым даже системный администратор будет пользоваться с трудом.
Решение должно быть простым и элегантным. И оно есть.
- В принципе любой более или менее владеет Excel (OpenWord или LibreOffice по функциям одно и тоже). А платежка есть таблица.
- Делаем нужную нам платежку в Excel, сохраняем ее в HTML (там есть такая функция).
- И у нас есть HTML таблица, которая и есть наша платежка.
- Теперь этот HTML код можно вставить в статью - и вот наша платежка уже видна пользователю.
- А теперь осталось каким либо образом поместить нужные цифры или буквы. Для этого нам нужно будет сделать плагин. А в тело нашей HTML таблицы вставить какие либо ключи которые будет понимать этот плагин. И этот плагин будет перед выводом платежки лезть в базу и подставлять вместо ключей информацию из базы.

Теперь по срокам. Сроки Я дал в расчете на одного себя. Занимаюсь я компонентом 4 дня в неделю (3 дня по 1-2 часа + 1 день по 3-4 часа), т.е. очень не много, поэтому и сроки озвучены такие долгие.
Если же ко мне присоединиться еще какой либо энтузиаст, то дело пойдет быстрее. Уже сейчас задача достаточно просто распараллеливается, в параллель можно делать 3-4 куска в принципе не пересекаясь друг с другом по коду.

Как я понял "платёжка" это аналог той "простыни", которую приносят обычн раз в месяц типчики с почты, для оплаты коммуналки, верно?

Как я понял "платёжка" это аналог той "простыни", которую приносят обычн раз в месяц типчики с почты, для оплаты коммуналки, верно?

Да. Она самая.

Да. Она самая.

Тогда всё много проще, там тариф достаточно умножать на объем, при наличии счетчика, а если счетчика нет, то брать установленный объем.

Тогда всё много проще, там тариф достаточно умножать на объем, при наличии счетчика, а если счетчика нет, то брать установленный объем.

По воде да. Именно так. И по другим статьям тоже.
Прикрепил для примера платежку которая мне приходит. В ней все поля должны быть заполнены из базы.
Часть полей - например плата за антенну - это фиксированный тариф который достаточно в базу 1 раз в год положить.
Часть полей - например плата за воду, плата за ТО (тех. обслуживание), вычисляется исходя из тарифа и фактического потребления (для воды) или площади квартиры (для ТО).
Но есть поля - например плата за освещение мест общего пользования (МОП) которые вычисляются ежемесячно бухгалтерией исходя из показаний общедомовых счетчиков. И плата по этим статьям различна от месяца к месяцу.

И у меня идея такая, что в HTML поле формы (таблицы) например для Тех. Осблуживания должно быть вписано что-то типа:
<func #__tarif.to * #__account.sq /func>
Плагин должен парсить HTML таблицу. Находить <func .... /func>. Ну а внутри этого ключевого поля уже лежит что собственно нужно выбрать из базы из таблицы #__tarif поле to (тех. обслуживание) и умножить его на то что лежит в базе в таблице #__account поле sq (площадь).
При этом плагин должен еще учесть что например ТО - это просто значение из поля таблицы базы данных, а sq - это площадь квартиры определенного собственника который в данный момент залогинился в системе. Но это решаемо.

И если такой плагин сделать, то система получиться достаточно гибкой. Администратор сайта сам сможет видоизменять и форму платежки и как угодно значения в таблицу выводить. Собственно нужно всего две операции обеспечить: прямой вывод значения из поля таблицы базы и операцию умножения.

[вложение удалено Администратором]

У тебя какая структура БД ?

Не придумывай, самое простое - личный кабинет, юзверь вводит данные - формируем отчёт и сэйвим его в БД, а на печать вывести можно в любом виде.

Вообще можно даже не формировать квитанцию, т.к. большинство пользуются ЕРЦ, а распечатать отдельные квитанции еще проще.

Т.е. оптимально иметь 5 таблиц.

1. Пользователи.
2. Тарифы.
3. Последние показания юзверя.
4. Счета (храним все).
5. Общие показания по дому.

Всё сведется к простым действиям - юзверь внес данные, записали их в таблицу 3, посчитали счета и записали их в таблицу 4, юзверю вывели платёжку (каждый может отверстать ее по своему), при этом у нас остается возможность вытягивать и формировать квитанции на основе полей из 4 таблицы, плюс поднять все счета за все периоды (опять же таблица 4), пользователь должен иметь доступ к редактированию только данных в таблице 3 и то только не более суток, после чего поля нужно перезаписывать, дать возможность выбора периода расчета.

У тебя какая структура БД ?

В смысле ?
InnoDB.

Сейчас сам гляну ((

Т.е. оптимально иметь 5 таблиц.

Ага. Понял.
Пока никакой. Этот этап Я еще не делал, поэтому таблицы пока не продумывал.
Но уже сейчас есть ряд таблиц приведенных к 3 НФ. В них содержится информация об адресе жильца и лицевом счете (в том числе площадь квартиры).

Да. примерно так как Вы описали мысль и идет.
Но фраза " посчитали счета и записали их в таблицу 4" - предполагает что в разных регионах страны и даже в разных УК "счет может производиться немного по разному". А фраза "юзверю вывели платёжку (каждый может отверстать ее по своему)" - предполагает что должна быть возможность верстки. А как указать что в HTML поле таблицы <td>здесь должна быть сумма по горячей воде</td> нужно вставить значение из какой либо таблицы базы данных Joomla ? Вот для этого Я так понимаю и понадобиться плагин.

P.S.: Таблица пользователи уже есть в Joomla - это таблица users.

Так...
#__tsj_city - города
#__tsj_street - улицы
#__tsj_address - адреса
#__tsj_account - профиль юзверя
#__tsj_water_office - только данные по водо-счетчикам
#__tsj_water_data - значения только для воды
#__tsj_gaz_office - только данные по газо-счетчикам
#__tsj_gaz_data - значения только для газа
#__tsj_electro_office - только данные по электро-счетчикам
#__tsj_electro_data - значения только для электроэнаргии
#__tsj_tarif - тарифы


Внимательно посмотри сам и поймешь, что усложняешь компонент. Своди всё к 5 таблицам, город и адрес это не критические значения.