Comment on page
🔑
Права доступа к данным
Способы решения типовых бизнес задач по работе с информацией. Большинство решений включает настройку структуру данных и системы прав доступа к данным.
Задача: Часть сотрудников должны видеть записи в каталоге, а другая часть сотрудников их редактировать. Например, все сотрудники могут видеть клиентов компании, но редактировать их могут только сотрудники отдела продаж.
Решение: Нужно создать несколько «правовых групп» и определить их права доступа к каталогу.
Задача: Сотрудники должны видеть записи в каталоге, и иметь возможность редактировать часть из них. Например, сотрудники могут видеть все заявки, но редактировать только не закрытые заявки.
Решение: Чтобы сотрудники могли видеть все записи нужно дать им доступ на просмотр в каталоге Заявок. Чтобы сотрудники могли редактировать часть записей, нужно создать вид в каталоге Заявок, который будет фильтровать записи, например по статусу. Дать доступ сотрудникам к этому виду на редактирование записей.
Задача: Сотрудники должны видеть и редактировать только определенные записи. Например, сотрудники могут видеть и изменять заявки, в которых назначены ответственным.
Решение: Чтобы сотрудники не видели все заяви, для них не должно быть правила на каталоге Заявок. Чтобы сотрудники могли видеть и редактировать назначенные на них заявки, нужно создать вид в каталоге Заявок, который будет фильтровать записи по ответственному используя фильтр «Я / Смотрящий». Дать доступ сотрудникам к этому виду на редактирование записей.
Задача: Сотрудники должны видеть анкету записи, редактировать её, кроме определенных полей.
Решение: Чтобы сотрудники не могли редактировать часть полей записи, нужно создать правило на каталог, разрешающее редактировать. Для этого правила задать исключения, какие поля редактировать н ельзя. Или наоборот, создать правило на каталог, разрешающее видеть записи, и исключение на поля, которые можно редактировать.
Задача: Часть плей карточки должны стать не редактируемыми для группы сотрудников если выбраны определенные значения в карточке. Например, нельзя менять ответ по заявке для закрытых заявок.
Решение: Чтобы сотрудники могли редактировать записи, нужно создать правило на каталог, разрешающее редактировать. Чтобы при этом часть полей стали нередактируемыми для определенных записей, нужно создать вид, фильтрующий такие записи, например с статусом закрыто. На этот вид дать группе сотрудников право редактировать записи с исключением на определенные поля.
Задача: В поле со связью с другим каталогом (выпадающий список) можно выбрать только определенные записи. Например, в карточке Задачи в поле «Проект» можно выбрать только открытый (по статусу) проект.
Решение: В каталоге проектов необходимо создать вид, фильтрующий записи, например по статусу. В каталоге задач поле «Проект» нужно связать не с каталогом Проекты, а с созданным видом.
Задача: В поле со связью с другим каталогом (выпадающий список) можно выбрать определенные для сотрудника записи. Например, в карточке Задачи в поле «Проект» можно выбрать только проект, закрепленный за сотрудником.
Решение: В каталоге проектов необходимо создать вид, фильтрующий записи для сотрудников, например по исполнителю. В каталоге задач поле «Проект» нужно с вязать с каталогом Проекты, установив галочку «Видны только доступные записи».
Задача: Сотрудники должны видеть анкету записи, за исключением некоторых полей. Например, не видеть оценку клиента по обработке заявки или служебную информацию.
Решение: В каталоге необходимо настроить правила доступа для нужной группы сотрудников к записям. В этом правиле настроить права на редактирование полей.
Задача: При выборе определенных значений в карточке, должны скрываться или показываться другие поля. Например при выборе в заявке типа «вопрос» должны быть показаны одни поля, а при тип «претензия» другие.
Решение: В редактировании карточки каталога настройте условия видимости полей в зависимости от других полей.
Задача: Набор возможных значений в выпадающем списке зависит от выбранного значения в другом выпадающем списке. Например, возможные значения в поле «Город», зависят от выбранного значения в поле «Страна».
Решение: В каталоге Города добавьте связанное поле с каталогом Страна и заполните его у городов. В каталоге клиента создайте два связанных поля с соответствующими каталогами: Страна и Город. При этом в параметрах поля Город система покажет свойство «Фильтр», которое позволит связать поле Город с значением в поле Страна.
Задача: Некоторые поля карточки должны стать обязательными, при определенных условиях. Например можно назначить статус заявки «в работе» только назначив исполнителя.
Решение 1: Поля карточки могут иметь требования к обязательности заполнения. Поле не видимое по условиям отображения не считается обязательным. Используя правила видимости полей можно определить условное требование к обязательности заполнения.
Решение 2: В более сложных ситуациях, когда обязательность зав исит от многих факторов, данных в других каталогах или внешних системах, можно использовать механизм событий. Событие «До изменения / до создания» запускается перед тем как изменения сохранены в базу. На это событие может быть прикреплен вебхук или процесс. Они могут проанализировать введенные сотрудником данные, информацию в других каталогах и системах, и принять решение: разрешить сохранение записи или нет. Если они блокируют сохранение, то изменения не будут сохранены в базу, сотруднику будет показано сообщение от вебхука/процесса и он сможет продолжить заполнять карточку записи.
Задача: Записи создаются автоматически и заполнены некоторыми данными. При этом в карточке есть обязательные поля, но они не заполняются при создании записи.
Решение 1: Поля карточки могут иметь требования к обязательности заполнения. Поле не видимое по условиям отображения не считается обязательным. Используя правила видимости полей можно определить условное требование к обязательности заполнения. Нужно настроить видимость обязательных полей так, что при создании записи через API эти поля были бы скрыты.
Решение 2: Поля можно сделать необязательными, а обязательность заполнения полей проверять через вебхуки или процессы аналогично тому как описано в кейса «обязательные поля при условиях».
Задача: После изменения записи сотрудником нужно внести в карточку записи дополнительные данные. Например после выбора типа и важности заявки установить «срок решения» исполнения и выбрать исполнителя.
Решение: Для автоматических действий с данными предназначен механизм событий. Событие «После изменения / после создание» запускается после того как изменения сохранены в базу. На это событие может быть прикреплен вебхук или процесс. Они могут проанализировать введенные сотрудником данные, информацию в других каталогах и системах, и манипулировать данными в этой записи и других каталогах.
Важно: Если вебхку/процесс будут изменять эту же запись, то вновь сработает событие, которое вновь запустит вебхук/процесс, что может повлечь зацикливание. Исключить это можно 2 вариантами:
а) Событие должно отслеживать только те поля, которые меняет сотрудник, а не вебкух/процесс.
б) Изменения, которые делает вебкух, он должен выполнять от специальной учетной записи. Если пришло событие, где автор изменений эта учетная запись, то вебкух должен игнорировать такое событие (не реагировать на собственные изменения). Аналогично в процессах, за исключением того, что в них автор изменения отсутствует.
Задача: Во время редактирования записи сотрудником нужно вычислять значения определенных полей. Например при вводе ИНН заполнить реквизиты, при выборе типа и важности заявки отобразить «срок решения», при выборе адреса подсчитать стоимость и срок доставки».
Решение: Для автоматических действий с данными предназначен механизм событий. Для автоподстановки данных в ходе заполнения карточки создано специальное событие «Во время редактирования», которое запускается при редактировании указанных полей в карточке. На это событие может быть прикреплен вебхук или процесс. Они могут проанализировать введенные сотрудником данные, информацию в других каталогах и системах, и вернуть новые значения полей для этой анкеты. Как в веденные поля (например отформатировать телефон), так и в другие поля.
Важно: Если вебхку/процесс будут изменять эту же запись, то вновь сработает событие, которое вновь запустит вебхук/процесс, что может повлечь зацикливание. Исключить это можно 2 вариантами:
а) Событие должно отслеживать только те поля, которые меняет сотрудник, а не вебкух/процесс.
б) Изменения, которые делает вебкух, он должен выполнять от специальной учетной записи. Если пришло событие, где автор изменений эта учетная запись, то вебкух должен игнорировать такое событие (не реагировать на собственные изменения). Аналогично в процессах, за исключением того, что в них автор изменения отсутствует.
Last modified 1yr ago