Подружить RLS с транзакциями #661967

Добрый день. В свое время занялся я как-то разграничением прав в своей УТ 10.3. Делать решил "по уму", т.е. по RLS. Вроде все там просто и понятно. Вроде все настроил. Но со временем то у того то у другого пользователя стали вываливаться ошибки при проведение документа "В данной транзакции уже происходили ошибки". Вот прекрасный пример: есть у меня роль "менеджер по продажам", положил я на документ "заказ покупателя" РЛС "Где Ответственный = &ТекущийПользователь". Красота. Видит он теперь только свои заказы. Но вот при проведении им нового заказа покупателя стали вылетать ошибки, которые ссылаются на общие модули. Что пробовал делать я: 1. Поменял РЛС на условие "#Если не &ЧтениеВсего #Тогда ГДЕ Ответственный = &ТекущийПользователь #КонецЕсли" и в Процедурах, в которых вылетала ошибка в начале запилил ПараметрыСеанса.ЧтениеВсего = Истина; и в конце "ПараметрыСеанса.ЧтениеВсего = ЛОжь"; Теперь все стало нормально проводиться, но после создания нового документа в форме списка заказов покупателя стал пропадать мой отбор по пользователю. И я даже понял почему: значение параметра сеанса меняется в среднем через 5-7 секунд после того, как пройдена строка ПараметрыСеанса.ЧтениеВсего = ЛОжь. Не знаю, с чем это связано. В результате - новое обновление списка документов происходит с ЧтениеВсего = Истина. 2е, что я пробовал: строки, на которые ругается 1с занести в "Попытка/исключение". Это порождает 100500 новых ошибок. Куда дальше смотреть, я уже ХЗ. Без РЛС все отлично работает. Накладывать на документСписок отбор и запрещать его менять - не тру. Подскажите, кто чем может :)

ИТС вообще не читаем? Влияние изменения значений параметров сеанса и функциональных опций на производительность механизма ограничения доступа к данным В процессе работы система формирует специальный кеш запросов ограничений доступа к данным, создаваемый для того, чтобы повысить производительность запросов получения данных при использовании ограничений. Ограничения доступа к данным могут использовать параметры сеанса и функциональные опции. В кеш попадают запросы ограничения доступа с установленными значениями параметров сеанса и функциональных опций. Однако, при изменении значений параметров сеанса или функциональных опций, которые используются в запросах ограничения доступа к данным, происходит очистка накопленного кэша запросов, что приводит к существенному снижению производительности запросов к данным. Не следует производить инициализацию параметров сеанса при запуске программы, так как: не все параметры сеанса запрашиваются из кода конфигурации при запуске программы. при работе программы возможно намеренное обнуление значений параметров сеанса из кода на встроенном языке. Правильным способом установки значений параметров сеанса является установка значений "по требованию". Т.е. параметры сеанса должны быть инициализированы только в тот момент, когда к ним происходит первое обращение, как к неустановленным. Не рекомендуется часто выполнять изменение значений параметров сеанса и функциональных опций в процессе работы системы.

Гуд, предложи, как сделать без параметров сеанса. Когда я это делал, это изначально позиционировалось как костыли.

>> Но вот при проведении им нового заказа покупателя стали вылетать ошибки, которые ссылаются на общие модули Вот тут непонятно

например: {ОбщийМодуль.УправлениеЗапасами.Модуль}: Ошибка при вызове метода контекста (Выполнить)    ТаблицаЗапроса = Запрос.Выполнить.Выгрузить; по причине: Ошибка выполнения запроса по причине: В данной транзакции уже происходили ошибки! Сам модуль большой, но полностью типовой

В запросе есть ссылка на запрещенный элемент списка, система возвращает ошибку после чего откатывается и транзакция

поставить галку на документ: проведение в привелигерованном режиме

Это я понял. Я не понял как обойти. Спасибо, щас попробую

в запросе написать " разрешённые"

Писал, не помогло. Разрешенные можно писать только в первом запросе, если есть ОБЪЕДЕНИТЬ все, то РАЗРЕШЕННЫЕ уже нельзя вставить

Тоже не помогло

Вот мне тоже нравится: {ОбщийМодуль.ОбщегоНазначения.Модуль(2670)}: Ошибка при вызове метода контекста (Выполнить)    Возврат Запрос.Выполнить.Выгрузить; по причине: Ошибка выполнения запроса по причине: В данной транзакции уже происходили ошибки! Понять не могу, че ей то не хватает?

Не факт, что ошибка именно в этом запросе... У меня было что-то подобное. Например, в одной процедуре считывался реквизит через точку у объекта на который не было прав, а ошибка вылазила в каком-то немыслимом месте. И из той же оперы: при проведении документа стартует бизнес-процесс, плюс в транзакции выполняется перезапись реквизитов и отсылается письмо на электронку. Стала появляться ошибка "В данной транзакции уже были ошибки" при обращении запросом к регистру сведений. Хотя реальная ошибка была в том, что ящик получателя емейла отсутствовал, и 1Ска не могла отправить письмо. Указали правильный емейл и ошибка исчезла. хз почему так.

А как отлавливал причину?

Отладчиком. Причем в некоторых местах, при попытке засунуть переменную в табло, отладчик намертво зависал.

Автор, отпишись, если докопаешься до истины. Любопытно.

такая же ситуация была вчера. Проводишь документ, вылетает с ошибкой при записи "В данной транзакции уже были ошибки", описание ошибки выдает что нет какого-тореквизита через точку, хотя он есть на самом деле, при попытке просмотра отладчиком виснет намертво. после 2-3х попыток проведения нормально проводится, ошибок нет и отладчиком просматривается объект. Пока не разбирался