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

Либо изначально неправильное требование заказчика, либо неправильно предложен вариант исполнения

Возможно вариант исполнения не правильный, но попробовав несколько способов я пришел к тому, что лучше всего динамически менять текст ограничения в шаблоне с помощью директив и параметров сеанса типа булево, чем использовать в запросе параметры сеанса типа фиксированный массив. Вот и получилось {ВидДокумента1...ВидДокументN}*{Чтение, Изменение, Добавление,Удаление}*КоличествоВидовРазграничения = приблизительно 3000

Как еще можно выполнить эту задачу. Например, надо гибко настраивать доступ к документу "Заказ". Настройка ограничений выполняется по Организации, Контрагенту, Направлению, Ответственному, Контрагент.ОсновнойМенеджер. И сочетать эти условия по произвольной логической формуле. Например: Условие1 И Условие2 или Условие3 И Условие4

Скорее всего у меня уже взгляд замылился, и наверняка можно выполнить эту задаче намного проще

(0) Я бы уже на 100-м параметр начал задумываться: а не несу ли я хуйню.
А аффтар ничего, до 3000 довел.

(5)Согласен полностью, затем сюда и пришел, может что-то вы предложите?

(6) Отложить в сторону бутылку и таки подумать.

Раз от разу вероятность того, что мне здесь помогут, снижается. Может хоть другой форум посоветуете?)

(8) Тебе там тоже не помогут. Ты же вместо вопросов просто свое видение излагаешь

(0)Даешь 3000 ролей :)

(9)Ну почему. У меня сплошные вопросы. Я же уже изложил конкретный пример и признал что вариант с 3000 параметрами немного бредовый. Просто в директивах процессора как я понял возможно использование параметров только типа булево или я ошибаюсь? А без директив процессора текст запроса всегда будет оставаться одинаково сложным

(0) зачем рлс, если ограничивать только данные документов?

(8) ну сходи на инфостарт, там тебе тоже скажут "дурачек"....

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

(8) Я же предложил гипотетически вариант упрощения запроса ограничения для того чтобы увеличить быстродействие, ни на чем не настаиваю. Можешь предложить свой способ, на то и форум нужен, не так ли? Мы же здесь не меня пришли обсуждать, а конкретную проблему. Например в УПП в отличии от данной задачи слишком мало способов разграничить данные иначе бы я от туда всё взял

(14) РС вида Пользователь-ТипЗначенияСтрокой-Значение(булево)
и ПередОТкрытием() проверяешь и ставишь Отказ

+(16) значение (чтототамссылка), разрешено (булево)

А сколько памяти надо для 3000 параметров сеанса?

(16) и (17) если я правильно понял, проверка будет выполняться на уровне формы, да? А как насчет отчетов? Недоступные элементы при такой блокировке всё таки будут попадать в отчеты, так ведь? И в формах списка они тоже будут присутствовать

(18) тип значения параметра сеанса булево то есть 3 кб

(20) меньше даже потому что не 3 киблобайта, а 3000 бит

Ради интереса проверил щас. Создал 1000 параметров типа строка 10. Все инициализировал. На пару метров память выросла.

(22) А если к ним пообращаться в цикле?)

Может так попробовать: Делаем справочник "Группы доступа". В группу доступа могут входить значения реквизитов, для которых нужно предоставить доступ и вид доступа(чтение, изменение и т.д.). Напиример: Группа доступа "Док. заказ" в группу входит "подразделение 1\чтение", "склад 2\чтение", "документ заказ\добавление". Дальше пользователю присваиваем группы доступа и пишем формирование запроса для РЛС на основании групп доступа.

(24) Если нетрудно, приведите пожалуйста примерный код запроса ограничения доступа в РЛС

Ограничение по реквизиту:

(
    (
        (Истина В
            (ВЫБРАТЬ ПЕРВЫЕ 1
                Истина
            ИЗ
                РегистрСведений.ДоступКОбъектам КАК Рег
                ЛЕВОЕ СОЕДИНЕНИЕ Справочник.ГруппыПользователей.ПользователиГруппы КАК Группы
                    ПО Рег.Пользователь=Группы.Ссылка
                    И Группы.Пользователь=&ТекущийПользователь
            ГДЕ
                Рег.Объект=Т.#Параметр(1)
                И Рег.Доступ
                И
                (
                    Рег.Пользователь=&ТекущийПользователь
                    ИЛИ Рег.Пользователь=ЗНАЧЕНИЕ(Справочник.ГруппыПользователей.ВсеПользователи)
                    ИЛИ НЕ Группы.Ссылка ЕСТЬ NULL
                )
            )
        )
        И
        НЕ (Ложь В
            (ВЫБРАТЬ ПЕРВЫЕ 1
                Ложь
            ИЗ
                РегистрСведений.ДоступКОбъектам КАК Рег
                ЛЕВОЕ СОЕДИНЕНИЕ Справочник.ГруппыПользователей.ПользователиГруппы КАК Группы
                    ПО Рег.Пользователь=Группы.Ссылка
                    И Группы.Пользователь=&ТекущийПользователь
            ГДЕ
                Рег.Объект=Т.#Параметр(1)
                И НЕ Рег.Доступ
                И
                (
                    Рег.Пользователь=&ТекущийПользователь
                    ИЛИ Рег.Пользователь=ЗНАЧЕНИЕ(Справочник.ГруппыПользователей.ВсеПользователи)
                    ИЛИ НЕ Группы.Ссылка ЕСТЬ NULL
                )
            )
        )
    )
    #Если "#Параметр(2)" <> "" #Тогда
        ИЛИ Т.#Параметр(1) ЕСТЬ NULL
        ИЛИ Т.#Параметр(1) = #Параметр(2)
    #КонецЕсли
)

Ограничение по таблице:

(
    (
        (Истина В
            (ВЫБРАТЬ ПЕРВЫЕ 1
                Истина
            ИЗ
                РегистрСведений.ДоступКОбъектам КАК Рег
                ЛЕВОЕ СОЕДИНЕНИЕ Справочник.ГруппыПользователей.ПользователиГруппы КАК Группы
                    ПО Рег.Пользователь=Группы.Ссылка
                    И Группы.Пользователь=&ТекущийПользователь
            ГДЕ
                Рег.Объект=#ИмяТекущейТаблицы
                И Рег.Доступ
                И
                (
                    Рег.Пользователь=&ТекущийПользователь
                    ИЛИ Рег.Пользователь=ЗНАЧЕНИЕ(Справочник.ГруппыПользователей.ВсеПользователи)
                    ИЛИ НЕ Группы.Ссылка ЕСТЬ NULL
                )
            )
        )
        И
        НЕ (Ложь В
            (ВЫБРАТЬ ПЕРВЫЕ 1
                Ложь
            ИЗ
                РегистрСведений.ДоступКОбъектам КАК Рег
                ЛЕВОЕ СОЕДИНЕНИЕ Справочник.ГруппыПользователей.ПользователиГруппы КАК Группы
                    ПО Рег.Пользователь=Группы.Ссылка
                    И Группы.Пользователь=&ТекущийПользователь
            ГДЕ
                Рег.Объект=#ИмяТекущейТаблицы
                И НЕ Рег.Доступ
                И
                (
                    Рег.Пользователь=&ТекущийПользователь
                    ИЛИ Рег.Пользователь=ЗНАЧЕНИЕ(Справочник.ГруппыПользователей.ВсеПользователи)
                    ИЛИ НЕ Группы.Ссылка ЕСТЬ NULL
                )
            )
        )
    )
)

Не совсем понял, а где будут храниться настройки гибкой логики условие1 или условие2 и условие3, например?

Логику можно попробовать описать в запросе через "ВЫБОР КОГДА", а хранить можно хоть в справочнике хоть в регистре

А вообще я бы сделал разные группы доступа для разных пользователей. т.е. если в группе доступа есть подр. 1 и подр. 2 и скл. 1 и контр. 1, то доступ даем. Как-то так. В твоем варианте задача слишком усложняется, скорее всего игра свеч не стоит, хотя ради интереса попробовать можно реализовать.

Ну да, что есть, то есть. Вот используя выражение "Выбор когда" я и столкнулся с проблемой быстродействия. Эта проверка будет выполняться вне зависимости от количества применяемых условий и как следствие будет все тормозить. Вот если бы как нибудь сделать так, чтобы запрос усложнялся только в случае увеличения числа условий

Срочно покурить документооборот на предмет формирования прав доступа на уровне записей фоновым заданием и складыванием оных в особый регистр

(32) Спасибо, сейчас скачаю