Возвращаясь к мысли об RLS и их оптимизации(это у меня периодически) снова задумалась как всё разрушить и построить новый мир в своей очередной подопечной базе.
Итак, немного об организации. Наша организация является комиссионером. Соответственно мы получаем заказ от комитента(а иногда мы уже третье лицо и к нам обращается агентство, в которое пришёл комитент), ищем подрядчиков, те выполняют заказ.
База 1С - оперативный учет состояния заказов и цепочек их движения между подрядчиком, а также формирование документов первички и закрытия по заказам.
Особенность иерархии созданной предыдущими программистами этой компании подразумевает то что у нас есть вот такие вот таблицы:
1) Справочник "Заказ", в справочнике хранится айдишник заказа.
1.2) справочник тип заказа
2) Справочник "Организация". Это наша организация.
3) Справочник "Подразделения". Это наши подразделения.
4) Справочник "Контрагентов". Контрагент может быть Агентством, Комитентом или Подрядчиком(исполнитель заказа).
5) Регистр сведений "Данные заказа". Содержит одно измерение, собственно ссылку на справочник "Заказ". В регистре сведений хранится куча строковых, числовых и ссылочных реквизитов(что-то порядка 30). В том числе есть реквизиты Организация, Комитент, Подрядчик,Кампания
4) Документы "Кампания". Именно через букву А, потому что это собственно рекламные кампании, которые включают в себя выполнение некоторого конечного набора
заказов. Документ имеет в качестве реквизитов кучу полей, в том числе Организация, Подразделение, Комитент, Агентство. В форме этого документа пользователи создают заказы большой красной кнопкой.
5) Регистр сведений "Подзаказы". У нас заказ может выполняться через каких то подрядчиков, иметь маржу, выполняться поэтапно и ещё всяко разно. В качестве измерения имеет ссылку на заказ, свой айдишник и подрядчика, в качестве ресурса - Организацию(не бейте! не я это сделала!!).
6) Задача от руководителя, объект метаданных задача. Иногда руководитель отсылает кому то задачу о работе с какой нибудь Кампанией независимо от того работает менеджер с этими заказчиками или нет, но менеджер должен эту кампанию срочно обработать.
Теперь о желабельной организации прав:
разделить пользователей на тех кто ограничен
1) только своей организацией(организация может включать в себя несколько подразделений)
2) только своим подразделением(подразделение может работать с несколькими нашими организациями)
3) только Брендами и видит всех комитентов в рамках этого бренда
4) только Агентствами
5) только отдельными Комитентами, у них даже бренда может не быть
6) Пересечением каких то из выше стоящих ограничений
7) Доступ к кампании на сновании задачи.
8) только по определённому типу заказа
Какой вариант организации РЛС я сейчас рассматриваю:
1) Создать перечисление "Тип ограничения". Значения: Организация, подразделение, агентство, комитент, подрядчик, тип заказа
2) создать регистр сведений. Измерения пользователь и тип ограничения
3) создать регистр сведений содержащий все разрешения пользователям. Измерения: Пользователь, тип ограничения, разрешённый объект справочника. Ресурс: запись или чтение
4) создать несколько ролей(на кампании, заказы, подзаказы, справочники - итого 4 штуки + одна роль на доступ по задаче!)
5) на справочники Организация, Контрагент, Подразделение навесить РЛС по группе пользователей и разрешённым объектам
6) Вот тут надо придумать как навесить рлс на роль документов Кампания, справочник Заказы и соответствующие регистры сведений, чтобы они выводились только если пользователю доступны все реквизиты, чтобы не пострадала производительность, не увязнуть в блокировках и т.д. Есть варианты случаев когда пользователь видит Кампанию в целом но не может видеть часть заказов или некоторые подзаказы - это у нас норма
Есть случаи когда пользователь ничего не видит, но если у него задача появляется то в рамках этой конкретной кампании, которая указана в задаче, он видит и организацию и подрядчиков и заказы и вообще всё.. вплоть до первички. Вероятно на эту роль надо сделать свои рлс на все справочники, регистры и документы?
Меня на данный момент смущает что при обращении через точку к реквизитам таблицы база очень страдает по скорости реакции, элементарно открыть список документов - удавиться можно на ожидании. Когда то года 4 назад на конфигурации документооборота я видела подобную реализацию и в целом там всё работало ок. Но там были управляемые формы, небольшая файловая база. У нас надо исходить из того что придётся экспериментировать с индексированием и таблицы регистров сведений и справочников могут быть гораздо более 800 тысяч строк. Если есть примеры реализации подобного на современных конфигурациях 1С, сориенируйте где глянуть?
UPD важный момент! организация структуры метаданных должна быть такой, чтобы можно было реализовать максимально простой интерфейс для пользователей по типу "взял пользователя и накидал ему комитентов/подразделений/чего то ещё с которыми он будет работать" так как основной задачей является передать процесс выдачи прав доступа ответственным руководителям.
небольшой оффтоп:
Kivals, ты уже 13 лет отвечаешь тут временами на совершенно обескураживающе тупые вопросы - откуда терпение берётся? на пользователях тренируешься? или ты уже отошёл от прямых контактов с смертными и общением с заказчиками не занимаешься?
