свободный набор полей

[nadayob]

хорошо бы иметь возможность иметь некоторую табличную часть или сущность со свободным набором полей.

например сценарий использования:
журнал учета обслуживания для инженерных систем.

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

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

[ktotut]

хорошо бы иметь возможность иметь некоторую табличную часть или сущность со свободным набором полей.

например сценарий использования:
журнал учета обслуживания для инженерных систем.

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

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

есть такой вот Плагин: он добавляет новый тип поля — «Таблица со свободным набором колонок».
Колонки берутся не из структуры приложения, а из обычного справочника, поэтому набор показателей
заводит рядовой пользователь, к администратору идти не нужно.

--------------------------------------------------------------------------------
ПО ПУНКТАМ
--------------------------------------------------------------------------------

1. «Табличная часть со свободным набором полей»

Поле-таблица внутри записи. Может быть в одну строку (один набор показаний на запись)
или в несколько строк, которые пользователь добавляет сам — например по одной на точку замера.

2. «Для каждой инженерной системы свой набор полей»

Колонки привязаны к единице оборудования. Открыли журнал, выбрали фильтр — видите давление
на входе и выходе. Выбрали электрощит — напряжение по трём фазам. Таблица перестраивается
сразу при выборе оборудования, сохранять запись для этого не нужно.

3. «Делать для каждой установки отдельную сущность неудобно — каждый раз к администратору»

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

4. «Иначе пользователь заведёт эксель, ведь там шапка делается за пару минут»

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

5. «Поле типа таблица, которое хранит свои данные для каждой записи»

Так и сделано: значения хранятся в самой записи журнала.

[support]

Я бы сделал следующую структуру сущностей:
А) Установки
Б) Журнал показаний
С) - Показания (под-сущность к Журналу)

В форме Журнала выбираем установку из списка (тип поля Сущность)
И добавляем Показания используя тип поля Форма вложенной сущности.
Сущность Показания имеет два поля: тип. показания и значение.

В результате мы соберем все показания в одной сущности Показания и сможем фильтровать по прибору и по типу показания и отследить изменения показаний по конкретному показанию.

Попробуйте так реализовать, возможно подойдет.

[nadayob]

Попробовал такой концепт.
Получается нужно выбирать набор полей КАЖДЫЙ раз при заполнении.
В таком случае нужна какая-то шаблонизация, или копировать каждый раз прошлую запись в журнал.
А с шаблонами в rukCRM у меня вообще как-то туго - каждый раз натыкаюсь на сильное ограничение функционала.

[nadayob]

есть такой вот Плагин: он добавляет новый тип поля — «Таблица со свободным набором колонок».

Где можно плагин посмотреть?

[ktotut]

есть такой вот Плагин: он добавляет новый тип поля — «Таблица со свободным набором колонок».

Где можно плагин посмотреть?

напишите мне личное сообщение

[nadayob]

а нельзя как-то раздел или конкретную сущность делегировать конкретному пользователю, чтобы он мог создавать в них сущности?

Я бы сделал следующую структуру сущностей:
А) Установки
Б) Журнал показаний
С) - Показания (под-сущность к Журналу)

В форме Журнала выбираем установку из списка (тип поля Сущность)
И добавляем Показания используя тип поля Форма вложенной сущности.
Сущность Показания имеет два поля: тип. показания и значение.

В результате мы соберем все показания в одной сущности Показания и сможем фильтровать по прибору и по типу показания и отследить изменения показаний по конкретному показанию.

Попробуйте так реализовать, возможно подойдет.

[nadayob]

Я бы сделал следующую структуру сущностей:
А) Установки
Б) Журнал показаний
С) - Показания (под-сущность к Журналу)

В форме Журнала выбираем установку из списка (тип поля Сущность)
И добавляем Показания используя тип поля Форма вложенной сущности.
Сущность Показания имеет два поля: тип. показания и значение.

В результате мы соберем все показания в одной сущности Показания и сможем фильтровать по прибору и по типу показания и отследить изменения показаний по конкретному показанию.

Попробуйте так реализовать, возможно подойдет.

вот ещё какая мысль по ситуации:
если позволить определённой группе пользователей (опытные пользователи например или начальники отделов) делать свои изолированные сущности и выдавать другим доступы то rukCRM может составить конкуренцию гуглоформам и даже экселю. А у гуглоформ аудитория больше чем у любых erp/crm/pm/helpdesk.

логика подобная во многих системах zero/low-кодинга используется. А где-то и подаётся как конкурентное преимущество.
Вот например в nextcloud tables как выглядит
https://apps.nextcloud.com/apps/tables
или даже в nextcloud forms или google forms
https://apps.nextcloud.com/apps/forms

Сценарий например такой:
Отдел hr хочет формализовать заявления на отпуск
Сами создают сущность с полями дата длительность фио
Дают ссылку персоналу и принимают заявления
Как бы они сделали в гуглоформах.
А потом уже администратор переделывает нормально за ними) но бизнес-процесс уже под контролем в системе, а не где-то в гуглоформах.

[ktotut]

Я бы сделал следующую структуру сущностей:
А) Установки
Б) Журнал показаний
С) - Показания (под-сущность к Журналу)

В форме Журнала выбираем установку из списка (тип поля Сущность)
И добавляем Показания используя тип поля Форма вложенной сущности.
Сущность Показания имеет два поля: тип. показания и значение.

В результате мы соберем все показания в одной сущности Показания и сможем фильтровать по прибору и по типу показания и отследить изменения показаний по конкретному показанию.

Попробуйте так реализовать, возможно подойдет.

вот ещё какая мысль по ситуации:
если позволить определённой группе пользователей (опытные пользователи например или начальники отделов) делать свои изолированные сущности и выдавать другим доступы то rukCRM может составить конкуренцию гуглоформам и даже экселю. А у гуглоформ аудитория больше чем у любых erp/crm/pm/helpdesk.

логика подобная во многих системах zero/low-кодинга используется. А где-то и подаётся как конкурентное преимущество.
Вот например в nextcloud tables как выглядит
https://apps.nextcloud.com/apps/tables
или даже в nextcloud forms или google forms
https://apps.nextcloud.com/apps/forms

Сценарий например такой:
Отдел hr хочет формализовать заявления на отпуск
Сами создают сущность с полями дата длительность фио
Дают ссылку персоналу и принимают заявления
Как бы они сделали в гуглоформах.
А потом уже администратор переделывает нормально за ними) но бизнес-процесс уже под контролем в системе, а не где-то в гуглоформах.

Могу дать доступ к демо.

[ktotut]

Всем доброго дня!

Вот более полное описание: viewtopic.php?t=11546