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

Даже реквизит ответственный наверное лишнее. Просто... определенный пользователь, может видеть только сотрудников, принадлежащих к определенной организации.

(1) RLS

(2) я так понимаю человек не вкурсе как с ним работать и о его существовании если он спрашивает... не думаю что твой ответ ему сейчас поможет
RLS за пару минут не освоить и не настроить как он хочет)

(2) rls в типовой конфигурации. Извиняюсь,не правильно сформулировала. У меня чистая конфигурацию. С нуля пишется

(3) человек в курсе и знает, как работать. в типовых конфигурациях работала. Я уточнила в чем проблема)

(4) сие есть большая тайна. так что т-сс. rls не только в типовых используется

но если это пугает, то вариантов реализации - множество. от банального реквизита в объекте "Организация для отбора" с доработкой списков и заканчивая сложной системой определения принадлежности

(6) ну чтобы не в типовой ее сделать, это большой объем достаточно))))Там платформа для исполнения минимума функций аххахаха

(8) Если конфа пишется с нуля.. то само собой дописывать РЛС это геморойно и объемно.
А вариантов как сказали множество. Хоть при октрытии формы списка или что там у тебя, отбирай, хоть как . "Кодом".

Ну как минимум механизм связи пользователя ИБ с элементом справочника Сотрудники нужно будет повторить или взять из типовой/БСП.

(9) Это вы не смотрели, как потом в коде люди пытаются определить видимость/доступность каких-то реквизитов, расписывая по фамилиям кому и что доступно. По сравнению с этой херней РЛС просто, легко и понятно
PS. (0) Советовал бы ответственных по организациям хранить в периодическом регистре сведений. Или нынешние сотрудники к вам пришли навсегда?

в свое время очень помогла статья https://infostart.ru/1c/articles/87531/

(0) Для корректных обсуждений следует уточнять моменты

- база пишется на какой версии платформы?
- разработка ведется с использованием БСП или нет?

Допустим. что это УФ (управляемые)

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

Я бы тоже, как rudnitskij выше предложил, что нужно иметь периодический регистр сведений, в котором указываются по измерению "пользователь" куча значений/условий.
А в произвольных запросах у динамических списков все эти условия будут срабатывать.

Кстати, даже при условии использования RLS, наличие периодического РС с описанием условий ограничения доступа не отрицается.
Но при начале сеанса все эти условия обрабатываются, чтоб дальше под RLS уже все работало.

Неоднократно видел поделки имитирующие РЛС. По итогу они оказывались полным гавном. Ибо постоянно приходилось докидывать объект хранения настроек в самой КФ и как бонусом, при отрисовки любой формы задействующей список, процедуры ограничения приходилось каждый раз прописывать программно на форме

(15) но из этого текста невозможно понять, что именно советуете сделать топикстартеру с озвученной в топике проблемой

(13) База пишется на платформе 8.3. Полностью с нуля, без библиотек. Задействованы обычные формы.

(0) RLS на роли, где дается доступ на чтение справочника "Сотрудники". С УТ 10.3 можно взять пример реализации по разрезу организациям + на будущее по контрагентам

(18) Под rls здесь имеется ввиду - написать свой шаблон ограничения и использовать в ролях его.

(17) тогда если кратко, то можно сделать так, как в (18) предлагается.

И в установке одного единственного шаблона ограничения нет ничего особо страшного. Это не так, как RLS сразу на всю типовую ERP написать, а всего лишь для одного справочника :-)