Rls что это такое
Настройка RLS в 1С — ограничение доступа на уровне записей
Ранее мы рассматривали настройку ролей пользователей в системе 1С Предприятие 8, сегодня мы продолжим изучение механизма прав и углубимся далее — в механизм RLS (ограничение прав на уровне записей).
Ниже мы рассмотрим достоинства и недостатки данного метода и рассмотрим настройку RLS в 1С Предприятии 8.3 на примере.
1С RLS (Record Level Security) или ограничение прав на уровне записи — это настройка прав пользователей в системе 1С, которая позволяет разделить права для пользователей в разрезе динамически меняющихся данных.
Самый распространенный вид настройки 1C RLS — ограничение видимости пользователя в разрезе организаций или клиентов (пользователь видит лишь «свои» данные).
Преимущества ограничения прав на уровне записей в 1С
Основное преимущество — наличие механизма вообще, механизм достаточно сложный и интересный. Позволяет очень тонко разграничить права пользователей — пользователи могут даже не догадываться о существовании в системе других данных.
Недостатки 1С 8 RLS
Среди недостатков можно отметить заметное падение производительности системы. Это вызвано тем, что платформа при построении запроса в базе данных осложняет любой запрос разработчика дополнительными условиями.
Также среди недостатков — сложность настройки этого функционала и сложность отладки. 1C выпустило очень мало материалов по настройке и работе этого функционала. Достаточно трудно найти специалиста, который грамотно настроил бы механизм.
Настройка ограничения прав на уровне записей 1С RLS
Ограничение прав на уровне записи (RLS) применяется для ограничения следующих типов прав:
##Если &ИспользоватьОграниченияПравДоступаНаУровнеЗаписей ##Тогда
ТекущаяТаблица ИЗ #ТекущаяТаблица КАК ТекущаяТаблица
ЛЕВОЕ СОЕДИНЕНИЕ (ВЫБРАТЬ РАЗЛИЧНЫЕ
СоставГруппы.Ссылка КАК ГруппаПользователей
ИЗ
Справочник.ГруппыПользователей.ПользователиГруппы КАК СоставГруппы
ГДЕ
СоставГруппы.Пользователь = &ТекущийПользователь) КАК ГруппыПользователей
ПО (&ИспользоватьОграниченияПравДоступаНаУровнеЗаписей)
ГДЕ (&ИспользоватьОграниченияПравДоступаНаУровнеЗаписей = ЛОЖЬ
ИЛИ (НЕ 1 В
(ВЫБРАТЬ ПЕРВЫЕ 1
1 КАК ПолеОтбора
ИЗ
РегистрСведений.НазначениеВидовОбъектовДоступа КАК НазначениеВидовОбъектовДоступа
ГДЕ
НазначениеВидовОбъектовДоступа.ГруппаПользователей = ГруппыПользователей.ГруппаПользователей
И ВЫБОР
КОГДА НазначениеВидовОбъектовДоступа.ВидОбъектаДоступа = ЗНАЧЕНИЕ(Перечисление.ВидыОбъектовДоступа.Контрагенты)
И ТекущаяТаблица.#Параметр(1) ССЫЛКА Справочник.Контрагенты
И НЕ ТекущаяТаблица.#Параметр(1) = ЗНАЧЕНИЕ(Справочник.Контрагенты.ПустаяСсылка)
ТОГДА ВЫБОР
КОГДА 1 В
(ВЫБРАТЬ ПЕРВЫЕ 1
1
ИЗ
Справочник.Контрагенты КАК Контрагенты ВНУТРЕННЕЕ СОЕДИНЕНИЕ РегистрСведений.НастройкиПравДоступаПользователей КАК НастройкиПравДоступаПользователей
ПО
НастройкиПравДоступаПользователей.ОбъектДоступа = Контрагенты.ГруппаДоступаККонтрагенту
И НастройкиПравДоступаПользователей.ВидОбъектаДоступа = ЗНАЧЕНИЕ(Перечисление.ВидыОбъектовДоступа.Контрагенты)
И (НастройкиПравДоступаПользователей.Пользователь = НазначениеВидовОбъектовДоступа.ГруппаПользователей
ИЛИ НастройкиПравДоступаПользователей.Пользователь = ЗНАЧЕНИЕ(Справочник.ГруппыПользователей.ВсеПользователи))
И НастройкиПравДоступаПользователей.Запись = ИСТИНА
ГДЕ
Контрагенты.Ссылка = ТекущаяТаблица.#Параметр(1))
ТОГДА ИСТИНА
ИНАЧЕ ЛОЖЬ
КОНЕЦ
ИНАЧЕ ИСТИНА
КОНЕЦ = ЛОЖЬ))
И НЕ ГруппыПользователей.ГруппаПользователей ЕСТЬ NULL)
##КонецЕсли
По сути, этот запрос каждый раз добавляется при запросе к таблице «#ТекущаяТаблица». Из чего можно представить, какую дополнительную нагрузку несет в себе механизм ограничения на уровне записи.
Как Вы видите, в запросе есть специальные параметры, например » &ИспользоватьОграниченияПравДоступаНаУровнеЗаписей». Это параметры в РЛС подбираются из объектов метаданных — «Параметры сеансов«. Как правило, они задаются при старте сессии пользователя.
Конструктор ограничения доступа к данным
Для удобства разработчика в 1С 8.3 есть специальная утилита для помощи в настройки РЛС — Конструктор ограничения доступа к данным. Он вызывается из поля «Ограничение доступа». Выглядит следующим образом:
Другие статьи по 1С:
Пример настройки RLS:
Если Вы начинаете изучать 1С программирование, рекомендуем наш бесплатный курс (не забудьте подписаться на YouTube — регулярно выходят новые видео):
К сожалению, мы физически не можем проконсультировать бесплатно всех желающих, но наша команда будет рада оказать услуги по внедрению и обслуживанию 1С. Более подробно о наших услугах можно узнать на странице Услуги 1С или просто позвоните по телефону +7 (499) 350 29 00. Мы работаем в Москве и области.
Ограничение доступа к данным на уровне записей (RLS) в 1С 8.3
Настройка RLS
Роли позволяют назначить права доступа на весь объект. Но иногда требуется разделить права доступа на конкретные значения объекта. Например, в справочнике контрагентов могут быть и покупатели и поставщики. И нужно, чтобы менеджеры по продажам видели только покупателей, а менеджеры по закупкам только поставщиков.
Для этого используются ограничения доступа к данным на уровне записей или RLS (Record Level Security).
RLS настраиваются в роли в группе Ограничения доступа к данным:
RLS настраиваются отдельно для каждого права. При этом ограничения можно настроить только для следующих прав:
В колонке Поля указывается список полей объекта, на которые настраивается ограничение. Можно выбрать Прочие поля, что значит ограничение на все поля объекта, кроме тех на которые явно настроены ограничения.
Для права Чтение можно настроить несколько ограничений. Между собой они будут объединены по условию И. У пользователя будут права только при выполнении всех ограничений.
На права Добавление, Изменение и Удаление можно настроить только одно ограничение.
Если на какое-то право были настроены RLS, то в списке прав они выделяются цветом, а также пиктограммой:
В примере выше RLS настроены для прав Чтение и Изменение.
Ограничения доступа можно настраивать для:
Язык ограничения доступа к данным
В колонке Ограничение доступа указывается текст самого ограничения. Он пишется на специальном языке ограничения доступа к данным, который является подмножеством языка запросов 1С. В тексте можно использовать только секции ИЗ и ГДЕ.
Если запрос из ограничения доступа вернет хотя бы одну запись или условие в секции ГДЕ будет истинным, то у пользователя есть права на этот объект базы банных. В противном случае прав не будет.
Простое ограничение доступа может выглядеть следующим образом:
Здесь Контрагенты — это псевдоним таблицы, а ГДЕ ИСТИНА — условие.
Таблица объекта, на который настраиваются ограничения всегда присутствует в тексте запроса. Именно ее псевдоним указывается в начале запроса. При необходимости можно добавить несколько таблиц в запрос:
Стоит отменить что в тексте запроса RLS нельзя обращаться к реквизитам и ресурсам регистра накопления или бухгалтерии. А также можно обращаться только к балансовым измерениям регистра бухгалтерии.
Примеры RLS
Чтобы лучше разобраться как работает RLS в 1С настроим ограничения доступа на справочник Контрагенты, чтобы менеджеры по продажам видели только покупателей.
У справочника Контрагенты есть реквизит ГруппаДоступа, который имеет тип ПеречислениеСсылка.ГруппыДоступаКонтрагентов:
По значению данного реквизита можно определить кем является контрагент.
Сейчас в списке контрагентов 2 покупателя и 2 поставщика:
Создадим роль Покупатели и для справочника Контрагенты и права Чтение настроим следующее ограничение:
И дадим пользователю только эту роль. В результате ему будут доступны только покупатели:
Удалим ограничение доступа для права Чтение и добавим такое же, но для права Добавление:
В результате пользователь может видеть всех контрагентов, но создать нового контрагента может только с группой Покупатели. Если указать любую другую группу, то будет выдана ошибка «У пользователя недостаточно прав на исполнение операции над базой данных»:
Удалим ограничение для права Добавление и добавим такое же для права Изменение:
Теперь пользователь может добавлять контрагентов с любой группой доступа, но изменять может только покупателей. При этом нельзя сначала изменить группу доступа на Покупатели, а потом изменить сам объект. Проверка выполняется как до изменения, так и после изменения.
Удалим ограничения для права Изменение и добавим такое же для права Удаление:
Теперь пользователь может и читать и добавлять и изменять любых контрагентов, но удалить может только покупателей. Именно удалить, а не пометить на удаление.
Вернем снова ограничение только для права Чтение, чтобы пользователь мог видеть только покупателей. Если сейчас пользователю дать еще одну роль, которая дает права на чтение и просмотр контрагентов, но для нее не настроены RLS, то пользователь увидит всех контрагентов. Так происходит, потому что из разных ролей RLS складываются по условию ИЛИ. Если хотя бы в одной роли нет ограничений, то считается, что разрешены все контрагенты.
Если для права Чтение добавить еще одно ограничение с условием:
Возможности типовых шаблонов ограничения доступа на уровне записей (RLS)
Во всех конфигурациях, созданных на базе БСП, применяются четыре стандартных шаблона для ограничения прав доступа к объектам на уровне записей:
В данной статье я рассматриваю основные возможности использования указанных шаблонов. Некоторые, специфические варианты применения рассматривать не буду по причине их кране редкого использования. При необходимости их можно посмотреть в описании приведенном на ИТС.
Перед прочтением, рекомендую посмотреть информацию про основные принципы реализации ограничений прав на уровне записей в типовых конфигурациях в этой статье. Здесь, я описываю исключительно применение типовых шаблонов, без подробного описания подсистемы в целом.
Наиболее часто используемый шаблон. Применяется, когда необходимо ограничить доступ по каким либо реквизитам объекта.
Значения всех параметров начиная с четвертого, это пары вид доступа – проверяемый реквизит объекта. Соответственно, шаблон поддерживает указание ограничений по 16 реквизитам объекта.
Проверяется соответствие реквизитов разрешенным значениям видов доступа для текущего пользователя. Для доступности объекта, разрешение должно быть найдено хотя бы в одной группе доступа, в которую включен пользователь, для всех указанных реквизитов одновременно. Также у пользователя должен быть доступ к данному объекту на уровне ролей.
Пример для выше приведенного ограничения доступа к документу «ПриобретениеТоваровУслуг»:
Для пользователя в настройках его групп доступа указаны следующие разрешения:
Следовательно, для данного пользователя будут доступны документы по складу «Основной», с подразделениями отличными от: «Администрация», «Отдел закупок».
В шаблоне #ПоЗначеним можно использовать конструкции на языке запросов для указания жестких отборов. Для этого используется специальный вид доступа «Условие»:
Также, можно проверить доступ на уровне ролей, к объектам, на которые ссылаются реквизиты проверяемого объекта (это может быть владелец проверяемого объекта или любой другой реквизит). Для этого, в качестве вида доступа необходимо указать «ПравоЧтения» или «ПравоИзменения»:
Шаблон необходимо применять, когда набор требуемых для проверки значений может быть различным для каждого конкретного проверяемого элемента. Это могут быть журналы документов, объекты в которых проверяемые значения находятся в табличных частях или иные случаи. Во всех выше перечисленных случаях необходимо заранее подготовить и записать наборы значений доступа для каждого проверяемого объекта. Соответственно, для доступности объекта, все значения набора должны быть доступны хотя бы в одной из групп доступа пользователей.
В качестве четвертого параметра можно указать ссылку на объект, который будет являться владельцем набора значений доступа. По умолчанию, эта ссылка на текущий объект.
Для использования шаблона, у каждого проверяемого вида объектов должна быть добавлена специальная табличная часть «Наборы значений доступа». В данную ТЧ перед записью объекта, помещаются значения доступа, которые должны быть доступны водной из групп доступа пользователя.
Сама же логика формирования значений видов доступа должна быть реализована в экспортной процедуре модуля объекта «ЗаполнитьНаборыЗначенийДоступа».
Пример из документа «Установка цен номенклатуры»
Все добавленные значения доступа проверяются по логическому «И». Если необходимо использовать более сложную проверку, можно заполнить дополнительный реквизит табличной части «Номер набора». Значения доступа, объединенные в разные наборы проверяются по логическому «ИЛИ».
Логика проверки будет следующей:
Само же заполнение табличной части объекта происходит в подписке на событие перед записью объекта «ЗаполнитьНаборыЗначенийДоступаТабличныхЧастей».
После этого в еще одной подписке на событие при записи объекта «ЗаписатьНаборыЗначенийДоступа», происходит перенос данных табличной части в специальный регистр сведений «Наборы значений доступа».
Шаблон #ПоНаборамЗначений при проверке разрешения на запись объекта, обращается к его табличной части, так как, если это новый объект, данных в регистре сведений еще нет. При проверке разрешения на чтение объекта, шаблон обращается к регистру сведений.
Шаблон #ПоЗначениям имеет одно серьезное ограничение – все заданные ограничения соединяются по логическому «И». Соответственно, нельзя указать такие условия, при которых объект будет доступен в случае доступности одного из нескольких указанных значений.
Для решения данной проблемы используется шаблон #ПоЗначениямРасширенный, который является расширенной версией шаблона #ПоЗначениям, и предоставляет возможности для применения логики «ИЛИ» для указания ограничений.
Как видно из примера, присутствуют дополнительные параметры, в которых можно задать логические связи используемых ограничений. Для указанного примера, документ будет доступен, при доступности организации и одного из двух кладов: «Склад отправитель» или «Склад получатель».
Также, в расширенном шаблоне можно указать дополнительные таблицы, которые необходимы для проверки. Допустим, можно указать табличную часть документа:
Реквизиты присоединенных таблиц также можно использовать в логике проверки доступности:
В случае с табличной частью, объект будет доступен, если будет доступен проверяемый реквизит (в данном случае «Номенклатура») хотя бы по одной строке.
Из-за того, что в шаблоне могут применяться дополнительные таблицы, требуется обязательное указания псевдонима основной таблицы «Т».
Последний, используемый шаблон предоставляет весь функционал предыдущего шаблона, с добавлением функционала шаблона #ПоНаборамЗначений. По сути, это объединение всех возможностей предыдущих шаблонов. Данный шаблон является самым «тяжелым» с точки зрения производительности, по этому не рекомендуется его применять без действительной необходимости.
Для реализации возможностей шаблона #ПоНаборамЗначений используется специальный вид доступа «Объект», с указанием ссылки на владельца наборов значений доступа, которые необходимо проверить:
В остальном, данный шаблон идентичен предыдущему шаблону.
Другие мои статьи по использованию механизмов БСП в типовых конфигурациях 1С
Использование подсистемы БСП «Заполнение объектов»
Новый подход к обмену данными EnterpriseData
Пример доработки правил конвертации без использования КД 3.0
Специальные предложения
Несмотря на то, что все это уже описано на ИТС, мне статья оказалась полезной для понимания тонкостей импользования шаблонов.
В свое время решал проблему производительности работы шаблона ПоЗначениямРасширенный, который из-за операции ИЛИ при соотношении малого количества разрешенных данных к большой выборке давал низкую производительность при выводе динамических списков. Недоразобравшись изобрел велосипед: добавил табличную часть и сделал свой запрос RLS, хотя мог бы использовать ПоНаборЗначений.
Такие обзорные статьи полезны: тот же материал, поданный по другому, позволяет увидеть тонкости, которые «замыленное» сознание не увидело в первоисточнике.
Честно говоря, складывается впечатление, что автор сам не понимает о чем пишет и переписал в своем исполнении инфу с ИТС, поэтому написано так же непонятно
После прочтения ИТС, лучше почитать «справку» в комментариях к самим шаблонам, тогда становиться более понятно
RLS – гибкая и тонкая настройка ограничений доступа к данным
Классическая задача: открыть пользователю доступ к какому-либо объекту, но не ко всем элементам / документам, а только к некоторым.
Или это может быть ограничение “все, кроме некоторых”.
Или ограничение не на справочники/документы, а на данные регистров…
По сути – это тонкая и очень гибкая настройка “что можно видеть этому пользователю, а о чем ему и не нужно догадываться”.
Почему именно RLS?
На большинстве внедрений требуется для разных пользователей установить различные уровни доступа к информации в базе.
В конфигурациях за возможные права доступа к данным отвечают специальные объекты метаданных – роли. Каждому пользователю информационной базы назначается одна или несколько ролей. Они определяют, возможны ли операции с конкретными объектами метаданных (чтение, запись, проведение и т.д.).
Часто бывает необходимо не просто открыть/запретить доступ к определенному объекту, а ограничить доступ к части данных в нем.
Только при помощи ролей решить такую задачу нельзя – для этого реализован механизм ограничения доступа на уровне записей (RLS).
Ограничения представляют собой условия, при выполнении которых действие над данными (чтение, запись и т.д.) будет разрешено. – так можно ограничить доступ не к объекту в целом, а только к части его данных.
Про RLS – более подробно: 8 видео и PDF
Поскольку это распространенная задача администрирования 1С – предлагаем посмотреть более детальные материалы:
PDF с вводной информацией.
21 страница, которые нужно прочесть сначала.
Видео 01:
Ограничение доступа к данным при помощи ролей
В этом видео рассказывается, как ограничивается доступ к данным при помощи ролей. Уточняется, что роли ограничивают доступ к виду объектов информационной базы (отдельный справочник, но не конкретные элементы справочника).
Видео 02:
Ограничение доступа на уровне записей (RLS)
В этом видео рассказывается о механизме ограничений доступа на уровне записей (RLS), когда можно настроить доступ не ко всему справочнику в целом, а к отдельным его элементам, в зависимости от хранящихся в информационной базе данных. Подобные ограничения прописываются в ролях.
Видео 03:
Реализация ограничения доступа на уровне записей для справочника Контрагенты
В этом видео рассказывается, как в демонстрационной конфигурации «Управляемое приложение» настроить доступ менеджеров только к собственным контрагентам, закрепленным за ними.
Видео 04:
Принцип работы ограничений доступа на уровне записей на низком уровне
В этом видео рассказывается, как платформа трансформирует запросы, передаваемые для выполнения на сервер СУБД, при наличии ограничений доступа на уровне записей.
Видео 05:
Совместное применение нескольких ограничений доступа на уровне записей
Пользователю информационной базы может быть назначено несколько ролей. При этом в каждой роли могут быть свои ограничения доступа на уровне записей. В этом видео рассказывается, как ведет себя система при наложении ограничений.
Видео 06:
Наложение ограничений методом ВСЕ
В этом видео описывается первый способ наложения ограничений на уровне записей – метод ВСЕ. При этом, если в выборку попадают записи, к которым доступ ограничен, будет выведено сообщение об ошибке.
Видео 07:
Наложение ограничений методом РАЗРЕШЕННЫЕ
В этом видео описывается первый способ наложения ограничений на уровне записей – метод РАЗРЕШЕННЫЕ. При этом в выборку попадут только те записи, к которым у пользователя есть права доступа.
Видео 08:
Исправление ошибки, возникающей из-за наложения прав доступа на уровне записей
В этом видео рассматривается, как при помощи ключевого слова РАЗРЕШЕННЫЕ исправить ошибку, возникающую под пользователем с ограниченными правами.
Не пропустите – все сразу и в полном объеме!
Этот курс позволит решать ВСЕ задачи по развертыванию и поддержке информационных систем на 1С.
Вот несколько тем из курса:
Даже на 3-5 пользователей. Тем более – если их хотя бы десяток…
Вам в любом случае когда-то придется разворачивать 1С, настраивать резервирование, права доступа, различные режимы запуска, тестировать целостность баз, обеспечивать работу серверов и т.д.
И лучше это сразу делать правильно.
Чтобы потом не было “…! Ну что за …! Твою же …!” – и прочих выражений сожаления 🙂
Комментарии / обсуждение (161):
Добрый день!
Используется конфигурация 1С:ERP 2.4. Учет в базе ведется более 3 лет, 150 пользователей.
Механизм ограничения доступа на уровне записей ранее не был включен. При включении опции “Ограничивать доступ на уровне записей” предупреждается, что выполнение заполнения данных при этом будет выполняться частями и может замедлить работу программы.
Вопрос 1. Заполнение данных, пусть и частями, будет выполнено один раз?
В курсе «Настройка и доработка прав доступа, профилей пользователей и RLS в типовых конфигурациях УТ 11.4 (11.3), КА 2.4 (2.2) и 1C:ERP 2.4 (2.2)» говорится, что при включенной указанной опции работа пользователей может быть замедлена в части работы интерфейса.
Вопрос 2. На сколько работа пользователей может быть замедлена, при размере базы 300 Гб?
Добрый день!
1. Для того, чтобы работали ограничения доступа на уровне записей, в служебных регистрах сведений должны быть записи, описывающие доступ к отдельным объектам.
До включения указанной галочки в регистрах не было нужных записей, значит, первоначально нужно сформировать эти записи по всей базе, затем поддерживать регистр в актуальном состоянии по мере заполнения базы новыми данными.
Для выполнения этого действия в конфигурациях на базе БСП (ERP как раз к таким относится) существует специальное регламентное задание, которое выполнит первоначальное заполнение (разовая операция), затем будет доформировывать записи для новых объектов (это уже будет регулярная операция, которая должна часто выполняться, чтобы для всех новых объектов базы были сформированы записи в регистрах, отвечающих за ограничения доступа).
2. Замедление работы зависит от нескольких факторов – какой режим ограничений будет выбран (стандартный и производительный), а также какое количество групп доступа будет у каждого пользователя. В общем случае – чем больше групп доступа у пользователя, тем сложнее может получиться запрос к СУБД, который извлекает данные из базы.
Поэтому рекомендуется провести нагрузочное тестирование на копии базы в условиях, приближенных к реальной работе пользователей. Тогда Вы точно сможете оценить степень замедления работы системы.
Добрый день!
Подскажите, пожалуйста, как можно с помощью шаблонов ограничения доступа ограничить доступ к данным некоторых отчетов. Например, есть профиль Менеджер по продажам, состоящий из нескольких ролей, у которого настроено ограничение доступа к группе партнеров. Исключения настроены в группе доступа. В отчете, например, Воронка продаж, нужно установить ограничение на разрешенную группу партнеров. А в другом отчете, например, Анализ встреч, по текущему пользователю, но также для пользователя с данным профилем.
Добрый день!
В типовых конфигурациях на базе БСП (например, УТ 11) в ролях используются стандартные шаблоны ограничений доступа из БСП.
Они универсальные, поэтому для решения большинства задач их не требуется менять. Предполагается, что настройку нужно выполнять в пользовательском режиме, создавая профили и группы доступа.
Если Вы ограничиваете доступ к справочнику Партнеры, оставляете доступными определенные группы, то в форме списка справочника, в списке документов, в отчетах будут видны данные только по этим разрешенным партнерам. Других (запрещенных) партнеров и данных по ним увидеть нельзя.
Если нужно в отчетах видеть не всех разрешенных партнеров, а только часть из них, то можно настроить отборы в отчете и сохранить такой вариант отчета. В отборе указать конкретных разрешенных партнеров, тогда отчет будет формироваться только по ним. Сохраненный вариант отчета можно разместить в Избранном, тогда пользователь сможет быстро формировать его, не выполняя предварительную настройку.
Добрый день, в учебной версии при использовании rls столкнулся с проблемой при записи или проведении документа (у пользователя недостаточно прав на использование операций над базой данных), причём в полной версии 1с данной проблемы не встречал.
В журнале регистраций ссылается на отказ доступа (действие-чтение)
Ограничение делал простое:
Как можно решить данную проблему?
Заранее огромное спасибо!
P.S.: не судите строго я недавно начал изучать 1с.
У учебной версии нет ограничений по RLS. Проверяйте, скорее всего у пользователя действительно недостаточно прав на использование операций над базой данных.
Добрый день!
Хотел уточнить, при установки ограничения по текущему пользователю на документ, сам пользователь проводить свои документы может или он их сможет только просмотреть и ему всё же будет отказано в доступе, как в моем случае?
Это зависит от-того на какое право наложено ограничение, чтение или запись.