Конфигурация - Бухгалтерия для Беларуси, редакция 2.1 Локализация для Республики Беларусь (2.1.41.3)
Есть задача - ограничить доступ пользователей в 1С к определённым организациям. То есть чтобы определённые пользователи не видели определённые организации и документы этих организация (реализация, поступление и все остальные).
База на MSQL Server.
Само ограничение не работает просто если включить "Ограничить доступ на уровне записей". Сначала нужно включить Константу "Использовать группы пользователей", добавить создать нового пользователя в отдельной группе, присвоить ему права.
Затем включить "Ограничить доступ на уровне записей" и настроить ограничения через "Группы доступа".
Проблема в том, что, если ограничить для пользователя какую-либо организацию - он всё равно будет видеть её в списках. При этом документы этой организации для пользователя видны не будут.
Подскажите пожалуйста, как сделать так, чтобы сама организация тоже не была видна.
Часто возникает необходимость в частичном ограничении доступа к данным. Например, когда пользователь должен видеть документы только своей организации. В таких случаях в 1С используется механизм ограничения доступа на уровне записей (так называемый, RLS – Record Level Securiy).
Для примера предположим, что перед нами стоит следующая задача. На предприятии ведется многофирменный учет и каждый контрагент и пользователь базы данных относится к определенной организации. Необходимо обеспечить доступ к справочнику “Контрагенты” таким образом, чтобы каждый пользователь мог просматривать, редактировать и добавлять контрагентов только своей организации.
Для решения задачи будем использовать платформу “1С:Предприятие 8.2″. Создадим новую конфигурацию в свойствах которой в качестве основного режима запуска будет выбран вариант “Управляемое приложение”.
Далее создадим справочник “Организации” и ещё два справочника – “Контрагенты” и “Пользователи” с реквизитом “Организация”. Кроме справочников нам понадобятся два параметра сеанса – “Организация” и “Пользователь” (соответствующих типов). Значения этих параметров устанавливаются при запуске сеанса работы с конфигурацией и хранятся до его завершения. Именно значения этих параметров мы и будем использовать при добавлении условий ограничения доступа на уровне записей.
Установка параметров сеанса выполняется в специальном модуле – “Модуль сеанса”
В этом модуле опишем предопределенную процедуру “УстановкаПараметровСеанса” в которой вызовем функцию заранее подготовленного общего модуля “ПолныеПрава”. Это необходимо в силу особенностей работы базы данных в режиме управляемого приложения, когда часть программного кода может выполняться только на стороне сервера (подробно на объяснении этих принципов в данной статье я останавливаться не буду).
В свойствах модуля “ПолныеПрава” необходимо отметить флажки “Сервер”, “Вызов сервера” и “Привилегированный” (последнее означает, что процедуры и функций данного модуля будут выполнятся без контроля прав доступа). Текст модуля будет выглядеть так:
В модуле управляемого приложения будем проверять наличие пользователя конфигурации в справочнике “Пользователи” (для простоты будем искать его по наименованию) и завершать работу системы если он не найден. Это необходимо для того, чтобы обеспечить заполнение параметров сеанса.
Теперь можем перейти непосредственно к описанию ограничений доступа. Для этого создадим роль “Пользователь” и перейдем на закладку “Шаблоны ограничений”, где добавим новый шаблон “КонтрагентыЧтениеИзменение” со следующим текстом шаблона: ГДЕ Организация =Организация #Параметр(1)
Текст шаблона ограничений является расширением языка запросов. В отличии от обычного запроса, текст ограничения должен в обязательном порядке содержать условие “ГДЕ”. В качестве значений параметров запроса (в нашем случае это “&Организация”) используются значения одноименных параметров сеанса. Конструкция вида #Параметр(1) означает, что на это место система подставит текст, переданный в качестве первого параметра в месте использования шаблона. С помощь приведенного шаблона будет выполняться проверка каждой записи таблицы (в нашем случае это будет справочник “Контрагены”). Для записей, значение реквизита “Организация” которых совпадает с заданным в соответствующем параметре сеанса, условие описанное в шаблоне будет выполняться. Таким образом эти записи будут доступны для чтения, изменения или добавления (в зависимости от того для какого из этих прав применяется шаблон). Продемонстрирую вышеизложенное на нашем примере.
Перейдем на закладку “Права” роли “Пользователь” и откроем список прав справочника “Контрагенты”. Будем использовать шаблон ограничений “КонтрагентыЧтениеИзменеие” для прав “Чтение”, “Изменение” и “Доблавление”.
Для права “Чтение” будем использовать шаблон с параметром “ИЛИ ЭтоГруппа”. При этом пользователям данной роли будет разрешено чтение не только элементов справочника “Контрагенты” своей организации, но и всех групп этого справочника.
#КонтрагентыЧтениеИзменение("ИЛИ ЭтоГруппа")
Поскольку при добавлении новых элементов справочника системой выполняется неявное чтение предопределенных реквизитов (это нужно, например, для нумерации), то необходимо обеспечить беспрепятственное чтение этих полей. Для этого добавим дополнительную строку с пустым текстом ограничения в таблицу ограничения доступа к данным и перечислим поля для которых действует данное правило – Ссылка, Версия данных, Родитель, Код.
Таким образом, поставленная задача ограничения доступа на уровне записей решена. Пользователи с действующими ограничениями получат доступ на просмотр и редактирование данных только своей организации.
Разработчики в управляемых приложениях применили новый механизм настройки прав доступа, о которых и пойдет речь.
Будут перечислены все те грабли, которые собрал автор, чтобы вы о них знали.
Наверняка, уже все знают, что из себя представляет новая система, поэтому предистория вкрадце:
Как было раньше( в обычном приложении):
Есть документ. Есть Роли - ПолныеПрава, ДокументНетДоступа, ДокументТолькоЧтение, ДокументЧтениеИРедактирование. В конфигураторе(аналогичный механизм в реж предприятия) вы выставляете пользователям эти роли и у них появляются соответствующие права доступа на документ. Все просто и скучно и даже зевать хочется.
С введением управляемого приложения разработчики решили усложнить(читается как расширить) настройки прав доступа.
Теперь:
Вводная та же. Чтобы дать пользователю какие-то права на документ - сначала вам необходимо создать элемент справочника Профили групп доступа. Это некий агрегирующий(суммирующий значения) объект, который объединяет роли в группы ролей. Теоритически таких профилей можно создать сколько угодно много с различным набором ролей( N*(n-1), где N - количество ролей), но на практике количество профилей определяется количеством должностных обязанностей пользователей в организации и их гораздо меньше, чем ролей.
Чтобы "привязать" эти профили к пользователям - нужно создать элементы справочника ГруппыДоступа. В типовых они создаются автоматически, когда вы отмечаете галочками профили для пользователя. Этот справочник соединяет профиль и пользователя(или нескольких пользователей).
При записи этого элемента справочника система автоматически добавляет роли (из профиля) в роли пользователя. Поэтому не стоит напрямую редактировать роли в конфигураторе, как раньше - при редактировании прав в Предприятии все роли в конфигураторе будут обновлены на роли из профилей пользователя. Кроме того, будет наблюдаться явное противоречение между набором профилей с ролями и ролями, установленными в конфигураторе.
Как хранятся роли в Профиле групп доступа, спросите вы. Ведь роли - это объекты МД, это не ссылочные типы. Отвечаю - для этого(и не только) разработчики создали служебный справочник ИдентификаторыОбъектовМетаданных, в котором хранится( в иерархии!) имена, синонимы, значения пустых ссылок всех объектов МД. Если вы хотите создать Профиль программно и добавить в него роль, то код примерно будет таким:
Но если мы добавили новую роль в конфигурации, то как она попадет в справочник? Хороший вопрос. У справочника ИдентификаторыОбъектовМетаданных есть метод, позволяющий обновлять его данные. это:
Процедуру следует запускать каждый раз, когда вы вносите изменения в метаданные, особенно когда изменяете роли, объекты, связанные с новыми ролями.
Отлично. Роль добавили, идентификаторы обновили.
Но обратная связь не работает - вы в режиме предприятия назначили пользователю профиль( с созданием группы доступа), а роль у пользователя в конфигураторе не добавилась! Что делать?
За синхронизацию ролей/профилей отвечает константа ПараметрыРаботыПользователей. Если роли не обновляются в конфигураторе, следует обновить её значение:
Хорошо, скажите вы. А как быть, если я хочу создать группы доступа программно? Да не вопрос. Единственное ограничение - не допускаются дубли связок Профиль-Пользоваль в группах доступа. Примерный код будет таким:
После выполнения этого кода, если все, что нужно обновлено - типовая конфигурация добавит пользователю роли.
Раз уж пошли по программному пути, вот код, который добавляет пользователя в справочник Пользователи и ПользователяИБ в ПользователиИнформационнойБазы:
Если вы добавляете не программно, то добавлять нужно из режима Предприятия - тогда пользовательИБ у вас сам создатся.
И если раньше, в обычном приложении, достаточно будет добавить польз в конфигураторе - и при заходе в Предприятие, этот польз сам создавался в спр Пользователи, то с управляемым приложением такой фокус не прокатит - система не даст зайти под пользователемИБ, которого нет в справочнике Пользователи.
Предположим, что в одной базе «Зарплата и Управление Персоналом» ведется учет по двум организациям «ООО» и «ЗАО». Существует три пользователя: Администратор, Бухгалтер ООО и Бухгалтер ЗАО. При этом стоит задача разграничить доступ бухгалтеров так, чтобы они могли видеть документы и отчеты только по своей организации. Первое, что необходимо сделать это зайти в «Настройки программы» и на закладке «Ограничение доступа» установить галочку «Использовать ограничение права доступа на уровне записей»:
После этого необходимо зайти в справочник «Группы пользователей» (Сервис -> Пользователи и права доступа -> Группы пользователей) и создать новую группу. Назовем её «Группа доступа к ООО». В табличной части «Состав Группы» добавим ссылку на пользователя «Бухгалтер ООО»:
Далее нажав на кнопку «Права» в форме созданной группы перейдем в «настройку прав доступа», где укажем на закладке «Организации» к каким организациям имеет доступ пользователи из группы «Группа для доступа к ООО», т.е. укажем организацию «ООО» и установим галочку в поле «Запись»:
Теперь если попытаться зайти под пользователем «Бухгалтер ООО» будет доступен ввод и просмотр данных только по организации «ООО».
Однако для того чтобы этот пользователь не имел возможности сам изменять выше описанные настройки, необходимо отследить какими ролями обладает этот пользователь. Это можно просмотреть, зайдя в базу под пользователем, имеющем полные или административные права. Далее необходимо открыть справочник «Пользователи» ( Сервис -> Пользователи и права доступа - > Пользователи ) и на закладке «Пользователи ИБ» кликнуть на пользователя, откроется окно «настройки пользователя информационной базы». Во-первых, необходимо чтобы пользователь не обладал ролями «Полные права» и «Право администрирование», иначе он будет иметь возможность сам изменять выше описанные настройки. Во-вторых, для того, чтобы пользователь вообще смог войти в базу необходимо установить галочку напротив роли «Пользователь». Далее можно расставлять роли в соответствии с тем, какие функции этот пользователь будет выполнять в программе. Выберем ему роли «Кадровик регламентированных данных» и «Расчетчик регламентированной зарплаты»:
Начиная с платформы 8.0 системы 1С Предприятие, существует возможность ограничивать права доступа пользователей на уровне записей. Для этого используется механизм RLS (Record Level Security). Такая «тонкая» настройка может быть полезна для ограничения доступа по организациям, клиентам, номенклатуре и др.
RLS – это возможность разработчика задать условие на таблицы базы данных для тех или иных пользователей (групп пользователей) и не дать им увидеть лишнего. Условие имеет булевый тип. Если значение условия принимает значение «истина», то доступ предоставляется, в противном случае – запрещается.
RLS используется одновременно с настройкой обычных прав доступа. Поэтому прежде чем приступить к настройке RLS, необходимо раздать обычные права на объекты конфигурации.
RLS применяется для следующих видов прав доступа:
* Чтение
* Добавление
* Изменение
* Удаление
Порядок настройки RLS
Рассмотрим простой пример выполнения настройки. Снимки экрана сделаны на версии 1С Предприятие 8.2 (8.2.9.356). Синтаксис шаблонов текстов ограничений описан в документации по 8.2 в книге «Руководство разработчика. Часть 1», поэтому на нем останавливаться не будем.
Итак, первым делом нужно определить шаблоны ограничений для каждой существующей роли.
После этого на основании указанных шаблонов задаются ограничения к необходимым объектам. Для редактирования текста условия можно воспользоваться конструктором ограничений доступа к данным.
Для редактирования нескольких ролей удобно управлять через окно «Все роли».
Для копирования условий в другие роли можно использовать окно «Все ограничения доступа». Шаблоны в другие роли могут копироваться только вручную.
Вот и все. Можно проверить результат.
Недостатки использования RLS:
1. Применение механизма ограничения доступа на уровне записей приводит к неявному увеличению таблиц, участвующих в запросе, что может привести к ошибкам в клиент-серверном режиме работы базы данных.
2. Для контроля записи бывает трудно или невозможно реализовать сложную логику приложения. В таких случаях лучше использовать условия в процедуре ПриЗаписи().
3. Написание условия (запроса) требует определенной квалификации разработчика.
4. Дополнительные трудности может создать невозможность отладки условия (запроса).
В типовых конфигурациях права на уровне записей могут быть заданы интерактивно для следующих объектов: организации, контрагенты, номенклатура, склады, подразделения, физические лица, заявки кандидатов и другие.
Следует помнить, что ограничения прав доступа на уровне записей довольно ресурсоемкий механизм и чем более сложные ограничения Вы поставите, тем медленнее программа будет работать, особенно при большой базе данных. Мелкоступов Александр
Когда требуется более тонкая настройка доступа, на помощь приходит механизм RLS - Record Level Security.
Конфигурации системы «1С:Предприятие» 8 изначально позиционировалась как программа для многофирменного учета, и один из первых возникающих вопросов – как бы сделать так, что бы пользователь видел только те данные, которые ему положено видеть, и никакие другие? Конечно, есть роли, с помощью которых можно разрешить или запретить то или иное действие над объектом конфигурации, есть интерфейсы, позволяющие минимизировать пункты меню. Но как быть в случае, когда к одному и тому же объекту конфигурации нужно организовать «интеллектуальный» доступ, скрывающий только определенный записи? Ярким примером служит справочник «Организации»: учет в базе ведется по нескольким фирмам, справочник физически один, документы по фирмам ведутся одни и те же. Понятно, что в этом случае в назначенных ролях пользователя нельзя просто убрать права на чтение и просмотр, нужна более детальная настройка - RLS.
Ограничения RLS можно задавать для следующих действий над объектами базы данных:
- Чтение – получение записей из таблицы базы данных;
- Добавление – добавление новых записей без изменения существующих;
- Изменение – изменение существующих записей;
- Удаление – удаление некоторых записей без внесения изменений в другие.
Ограничение доступа задаётся подмножеству, определяемому условием выборки, заданному с помощью языка запросов. Если результат выполнения запроса ИСТИНА, то доступ на определенное действие будет предоставлен, в противном случае доступ будет запрещен.
Пример запроса:
В качестве переменных в запросах RLS используются специальные объекты конфигурации – параметры сеанса. Кроме привычных типов объектов, тип параметра может быть такжеNULL, УникальныйИдентификатор, ФиксированныйМассив, ВидДвиженияНакопления и др. Особо хочется отметить тип ХранилищеЗначений, позволяющий хранить разнородные данные в одном параметре (например, ОбщиеЗначения). Значения параметров сеанса обычно задается в процедуре ПриНачалеРаботыСистемы.
Так, при выводе списка номенклатуры можно отображать только некоторые группы справочника, при выборе контрагента в документ можно показывать не всех контрагентов, а только тех, к которым позволено работать пользователю, при формировании отчета скрывать данные по определенному подразделению. Вариантов применения RLS масса, нужды бизнеса иногда диктуют порой умопомрачительные требования, например разграничения доступа к проектам и спецификациям.
Заданные ограниченияRLS добавляются системой к каждому запросу, каждому действию с базой данных. Поэтому необходимо помнить, что злоупотребление механизмом RLS чревато снижением быстродействия системы.
В типовых конфигурациях возможность настройки прав доступа на уровне записей организована только для групп пользователей. Т.е. каждый пользователь системы включается в одну или несколько групп, для которых настраивается правило доступа к объекту или множеству элементов. Чем в большее количество групп входит пользователь, тем ниже будет производительность системы.
Платформа 1С в явном виде не предоставляет возможность отладки работы механизма RLS, но тем ни менее сделать это вполне реально. Для этого можно воспользоваться универсальной консолью отчетов (версия не ниже 2.6.9.2), на закладке «Данные» у которой есть функция «Выполнить от имени». Обработка создаст COM-соединение с помощью указанного имени пользователя и пароля, и выдаст результат выполнения запроса в консоль.
Используя имеющиеся в конфигурациях шаблоны ограничений, или создавая свой собственный запрос с помощью конструктора ограничений доступа к данным, можно настроить работу базы данных до мельчайших деталей, расписав кому что видно, доступно и дозволено. Единственным минусом является снижение производительности базы данных, но, как говорится, всё хорошее должно быть в меру.
В основе работы с XML-файлами лежит технология доступа SAX, которая осуществляет считывание по одному тегу. Для этого существует два типа данных – ЗаписьXML и ЧтениеXML. Запись данных справочника в XML-файл:
Чтение данных из XML-файла в справочник:
Создадим обработку в типовой конфигурации для экспорта плана счетов. Структура xml-файла должна быть такой. Корневой элемент xml-документа соответствует плану счетов в целом. В нем располагаются подчиненные элементы с именем Счет, содержащие информацию о счетах. В качестве содержимого элементов указывается наименование счета. Остальные данные записываются в качестве атрибутов (код, признаки валютного, количественного учета и пр.). В качестве подчиненных элементов для элемента Счет задаются элементы, обозначающие его субсчета с теми же атрибутами. Приведем код процедуры экспорта плана счетов.
В результате будет получен файл, вот его фрагмент:
А теперь приведем код для импорта плана счетов из xml-файла в новую конфигурацию. Код модуля соответствующей обработки должен содержать процедуру Выполнить(), которая имеет такой вид.
Ограничение пользователей по организациям. Прошу помощи. 
