Что выбрать параметры сеанса, экспортную переменную модуля приложения или функци #608684

Недавно начал переводить конфигурацию с 8.1 на 8.2. И хочется услышать мнение более опытных коллег в 8.2. Задача следующая есть база головного офиса и распределённая база удалённого офиса. И в удалённом офисе существуют некие ограничение на просмотр списков документов и отчётов, так же возможны другие ограничения в правах. Часть ограничений реализуются на уровне прав, но часть приходится ограничивать на уровне отборов. Т.е. скатим открывается открывается форма списков документов реализации и сразу накладывается фильтр на только доступные подразделения. Вопрос в следующем. как это более грамотно реализовать. Где лучше всего хранить признак того что это головной офис? Думал использовать параметр сеанса, но меня смутила фраза с ИТС: 1.2. Не рекомендуется использовать параметры сеанса для хранения значений, используемых исключительно в клиентской логике. Поскольку в клиент-серверном варианте 1С:Предприятия параметры сеанса хранятся на сервере, то любое их считывание или изменение в процессе работы на клиенте потребует дополнительного серверного вызова и увеличит объем передаваемых данных с клиента на сервер и обратно. В таких случаях следует использовать глобальные переменные модуля управляемого приложения (и обычного приложения – для режима обычного приложения, соответственно). А у меня в большинстве случаев это именно управление именно интерфейсом, но иногда придётся узнавать параметр и в модуле документов. Может можно как-то функциональную опцию для этих целей использовать. Но я с этим механизмом пока не работал. Помогите принять решение.

есть метод ГлавныыйУзел. Если вернет Неопределено, то ты в головном офисе. Мне кажется, отборы не лучший вариант, может - ограничения прав доступа шаблонами (РЛС). Там, правда, поразбираться придется, зато красиво, в типовых видел вроде так как-то сделано, есть группы доступа, в зависимости от них можно доступ к объектам настраивать.

Как определить головной офис или нет я знаю. Вопрос где хранить этот признак. Для РЛС это придётся использовать параметры сеанса. Но РЛС наверно не подойдёт. у меня в удалённый офис все документы мигрируют, но вот просматривать нужно только свои. А про группы доступа сп. посмотрю. Но вопрос больше риторический в каких случаях лучше использовать параметры сеанса, а в каких экспортные переменные.

UP

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

Обмен проходит вручную причём несколькими пользователями. Т.е. чтобы пользователь при обмене мог добавить документ ему нужны права на чтение всех документов. Значит мне РЛС не подходит. Я же не могу настроить права на просмотр документов согласно условию. Экспортные переменные модуля приложения видны на клиенте в модуле формы и поэтому я  могу например при открытии установить значение реквизита, который будет использоваться в условном оформлении формы. Аналогично я могу при создании на сервере установить значение реквизита из параметра сеанса. Т.е. в обеих случаях обойдусь без серверных вызовов. Но что лучше использовать согласно методологии 1С 8.2? Хочу для себя решить чтоб в будущем поступать по аналогии.

Реализовать такое правильнее всего на уровне ограничения прав. В таком случае данные будут отбираться еще при чтении с сервера. Неправильно тут думать, что производится доработка клиентской, интерфейсной части: тут ограничивается доступ к данным, а данные хранятся на сервере. Ну а ограничивать доступ к данным в правах удобно с использованием параметров сеанса (переменные туда и не передать никак). Также можно использовать какие-то вспомогательные таблицы (например, регистр сведений со списком доступных отборов - если пользователю доступна, скажем, не одна организация, а несколько).

А как обмен тогда делать. Если у пользователя будут существовать ограничения на доступ к данным, то он не сможет добавить (изменить) объект при обмене.

Как вариант можно конечно попробовать установить во время обмена некий флаг который снимает ограничение на права доступа.

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

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

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