Добрый день.
Очередной идиотский вопрос от меня.
Пишу самописную конфигурацию по учету ТМЦ на предприятии. В организации есть несколько филиалов, в каждом из них работает сотрудник, который приписан только к нему.
Задача стоит, чтобы сотрудник видел информацию только по своему филиалу (документы перемещения, расходования, прихода, инвентаризации и сотрудников), но не используя RLS (снова так захотел аналитик).
Я, честно говоря, снова подвис.
В голову приходит только мысль запихивать в событие формы списка документов или справочников условие на то, что если пользователь не обладает достаточными правами, то ему будет отображаться только информация по его филиалу (берется из реквизита филиал справочника "Пользователи") и в каждом документе есть подобный реквизит.
Вот только что-то завис с реализацией.
Использую управляемые формы.
По идее, в событии при Открытии я должен написать что-то типа:

```1c
    ЭтаФорма.Список.Отбор.Филиал.Значение =ТекущийПользователь.Филиал;
```

Но ни черта не работает. Сейчас сижу уже тупо варианты перебираю. Этот код пытаюсь вызвать с директивой на клиенте, может в этом дело (хотя ошибка почему-то не падает). Уже думаю использовать произвольный запрос в списке.
В общем, хожу вокруг да около, но что-то криво все реализую
---
У (1) RLSик то простенький. Добавить в ПараметрыСеанса Филиал, заполнить его и в Ограничениях всего то

```1c
    Где Филиал = &Филиал
```

Условие отработает быстро. Это не в типовых, где трехэтажные условия по различным параметрам с соединениями и вложенными запросами
В общем была похожая задача год назад, 2 справочника типовых, пять документов самописных, три типовых, ограничение по подразделению пользователя. База за 200 ГБ. Тормозов и проблем за год не обнаружено . Роль написалась за 2 часа, Ну там по отладке в запросы вставить Разрешенные пришлось. Где то схитрил, поставив в ограничение не все поля (модуль менеджера закрыт, а ОбработкаПолученияДанныхВыбора есть), установив программно ПараметрыВыбора
---
В управляемых формах отбор устанавливается чуть сложнее, но только внешне:

```1c
    ЭлеметОтбора = Список.Отбор.Элементы.Добавить(Тип("ЭлементОтбораКомпоновкиДанных"));
    ЭлементОтбора.ЛевоеЗначение = Новый ПолеКомпоновкиДанных("Филиал");
    ЭлементОтбора.ВидСравнения = ВидСравненияКомпоновкиДанных.Равно;
    ЭлементОтбора.ПравоеЗначение = ТекущийПользователь.Филиал;
```

Ну а что касается задачи в целом. Задавали ли Вы вопросы аналитику о том, как он представляет себе реализацию такого ограничения доступа к данным в дальнейшем? Необходимо будет и в документе сделать проверку на корректность введенного филиала? И в отчетах? Понимает ли он, что при таком подходе добавление новых объектов конфигурации усложняется, т.к. всегда нужно будет помнить и предусматривать ограничение доступа к данным в разрезе филиалов? Т.о. та работа, которую мы благодаря RLS поручаем делать платформе, полностью ложится на Ваши плечи. Ну и в конце концов, в чем именно Ваш аналитик видит выигрыш от использования собственных отборов по сравнению с использованием механизма RLS?
---
По поводу отказа от RLS - он мотивирует это только тем, что при помощи отборов можно все быстрее сделать и не заморачиваться с RLS. Типа, RLS только усложнит все.
В отчетах от тоже считает, что все при помощи отбора легко решается. Документы, в свою очередь, будут создаваться с заполненным филиалом, который будет браться из реквизита пользователя (тут уже это как я думаю).
Скорее всего, аналитик отталкивался от Ут 10.3 и хотел подобную реализацию на обычных формах. На УФ это уже я захотел сделать, потому и расхлебываю подобное.
А подскажите, приведенный Вами код прописывать там, где я и хотел - в событии "При Открытии"?
---
Опять ваш аналитег выпендривается:). Согласен с (2). Если объем небольшой, то лучше РЛС
Сам писал систему на отборах, но так хотел архитектор.
Поле Филиал не доступен. В новых должен подставляться автоматически
Отбор по спискам лучше вывести куда нибудь в серверный общий модуль.
Что то вроде

```1c
    Процедура УстановитьОтборПоОрганизации(Список) Экспорт
    ЭлементОтбора = Новый ПолеКомпоновкиДанных("Организация");
    Для Каждого Отбор из Список.Отбор.Элементы Цикл
    Если Отбор.ЛевоеЗначение = ЭлементОтбора Тогда
    Отбор.Использование = Истина;
    Отбор.ПравоеЗначение = Филиал;
    Отбор.РежимОтображения=РежимОтображенияЭлементаНастройкиКомпоновки­Данных.Недоступный;
    Возврат;
    КонецЕсли;
    КонецЦикла;
    Отбор = Список.Отбор.Элементы.Добавить(Тип("ЭлементОтбораКомпоновкиДанных"));
    Отбор.Использование = Истина;
    Отбор.ЛевоеЗначение = ЭлементОтбора;
    Отбор.ПравоеЗначение = ТекущийПользователь.Филиал;;
    Отбор.РежимОтображения=РежимОтображенияЭлементаНастройкиКомпоновки­Данных.Недоступный;
    КонецПроцедуры
```

И вставлять ее в ПриСозданииНаСервере.
В каждой форме, где есть поле Филиал, программно заполнять ПараметрыВыбора. Кстати тоже можно вынести в общий модуль
В общем писанины много
---
))) По поводу писанины и ненужно много, мне нужен пинок в нужное направление, как тому пингвину)) Спасибо за подобные подсказки. Хотя бы они уберегают от написание какого-нибудь монструозного и неправильного кода.
А насчет аналитика... Он все время кичится тем, что у него опыта 10 лет в разработке и все слабые стороны того или иного решения он уже видит на глаз. Потому и приходится вот такую ерунду изобретать.
RLS, кстати, я начал внедрять, но мне его беспощадно забрили, типа, проблем в дальнейшем будет больше
---
Блин. У меня 22 года разработки за плечами и знаю, что я мало знаю:) Но то что на РЛС проще и задача решается очень быстро знаю точно
---
очевидно ваш аналитик не понимает, что для его задачи и нужно RLS использовать. А написание отборов это потенциально дыра в решении этой задачи, плюс наоборот сложность в контроле и поддержке. Скорее всего аналитик не опытный, а 10 лет сидел на ТП.
Есть еще механизм разделения данных, но это вообще для других целей.
---
В общем, один черт не знаю, как решить такую задачу как он хочет и буду делать через RLS. Заставит переделывать, значит, заставит. Просто у меня тоже квалификация весьма низкая, потому и не могу на свои решения говорить, что они оптимальные.
---
А кто может говорить на свои решения что они оптимальные?
---
Я тоже честно пыталась понять RLS, но ничего кроме объект не найден повсюду или что отчёты без предупреждения в отборах или настройках показывают совершенно разные цифры не увидела.Может что не так делаю..
Как пользователь под RLS я не понимаю, что же в конце концов есть и чего не должно быть.
---
А в чем проблема RLS?
---
Проблем, говорит, в дальнейшем не оберешься. На пяти справочниках и четырех документах...
---
А если большой объем тогда что?
Вообще убрать все журналы и справочники, сделать обработки и выбор справочников с перехватом и заменой на список значений, как было во всеми нами горячо любимой семёрке?
---
Семерку, к сожалению, не застал. Да и не думаю, что аналитик тоже (ему 30 лет). Поэтому сказать наверняка не могу.
Просто досадно, что с одной стороны, задача реально простая с этой конфигурацией - обычно такие во всех учебных курсах разбирают кроме добавления пользователей, RLS и прочей ерунде. Но некоторые хотелки просто с ума сводят.
Начиная от формы регистра накопления, в котором вот не должно быть регистратора и хоть ты тресни.
Или приходится изобретать идентификационные номера номенклатуры, исходя из филиала, к которому относится та или иная группа номенклатуры.
В общем, не знаю. Потихоньку делаю, забреет, так забреет.
---
А кому вообще нужна форма регистра накопления?
---
А вот это тайна за семью печатями. Типа, сотрудники должны в ней видеть, что приходило и что уходило. Один черт, в эту форму я добавил кнопки вызова того или иного документа, ответственного за свою хозоперацию. В общем, ерунда какая-то получается.
---
в принципе логично. Я бы даже заменила журналы накладных на список регистра взаиморасчётов. А отбор по виду документа там есть (чтобы кассу не все видели)?
А движения по зачёту авансов можно не делать, раз уж аванс для взаиморасчётов не актуален.
---
Простите за глупый вопрос - что именно логично? Мозги просто сегодня от обилия задач в осадок ушли, уже туплю. Отбора по виду документа нет.
---
что сотрудники должны видеть, странно, что проблемы видит только аналитик. Видимо его это больше касается.
---
У (1) RLSик то простенький. Добавить в ПараметрыСеанса Филиал, заполнить его и в Ограничениях всего то

```1c
    Где Филиал = &Филиал
```

Условие отработает быстро. Это не в типовых, где трехэтажные условия по различным параметрам с соединениями и вложенными запросами
В общем была похожая задача год назад, 2 справочника типовых, пять документов самописных, три типовых, ограничение по подразделению пользователя. База за 200 ГБ. Тормозов и проблем за год не обнаружено . Роль написалась за 2 часа, Ну там по отладке в запросы вставить Разрешенные пришлось. Где то схитрил, поставив в ограничение не все поля (модуль менеджера закрыт, а ОбработкаПолученияДанныхВыбора есть), установив программно ПараметрыВыбора
---
Спасибо, попробую -отпишусь и отмечу) Спасибо