1с при проверке ролей для пользователей найдены ошибки
Допустим, мы добавили новую роль в конфигурацию. Потом добавили её в профиль группы доступа и назначили соответствующую группу доступа пользователю. Однако, в конфигурациях на основе БСП все известные программные проверки данной роли при включении пользователя в предопределенную группу доступа "Администраторы" не работают. В статье приведено решение данной задачи.
Проверка с помощью функции глобального контекста РольДоступна()
Если в программном коде необходимо проверить установлена ли какая-либо роль у текущего пользователя, то можно воспользоваться функцией глобального контекста РольДоступна(), которая возвращает значение Истина, если указанная в скобках роль доступна и Ложь, если не доступна.
Однако, в конфигурациях на основе БСП при включении пользователя в предопределенную группу доступа Администраторы, пользователю назначаются только две роли: Полные права и Администрирование (в этом можно убедиться с помощью Конфигуратора: Администрирование - Пользователи - Пользователь - Прочие). Все остальные роли отключаются вне зависимости от того, включен ли пользователь в какие-либо еще группы доступа. Система считает, что другие роли этому пользователю не нужны. Поэтому функция РольДоступна() возвращает в этом случае Ложь, что не подходит для решения нашей задачи.
Проверка с помощью функций БСП
Проверить наличие роли можно также с помощью функций БСП: Пользователи.РолиДоступны() и УправлениеДоступом.ЕстьРоль(). Но данные функции для полноправного пользователя (с ролями Полные права или Администратор системы) вернут всегда Истину независимо от того, назначена ли данная роль пользователю или нет:
Можно было пойти по легкому пути, скопировать данные функции и убрать в них проверку на полноправного пользователя, но мы не ищем легких путей это бы нам не помогло, так как функция Пользователи.РолиДоступны() все равно используют функцию глобального контекста РольДоступна(), а функция УправлениеДоступом.ЕстьРоль() слишком громоздка (текст функции около 300 строк при этом текст основного запроса около 200 строк).
Таким образом, все перечисленные известные функции не подходят для решения нашей задачи.
Решение
Для решения этой задачи в любой конфигурации на базе БСП я использую свою функцию:
Буду признателен, если Вы будите делиться своим опытом решения данной задачи.
При выполнении обработки по обновлению вспомогательных данных столкнулся с ошибкой - Роль "Полные права" содержит право Изменение неразделенного объекта Справочник.Заболевания.
И таких ошибок много, ругается на разные роли, справочники, документы и регистры. На все объекты, которые я добавил в расширение. Роли в расширение не добавлял.
Чуть позже добавил свою роль и добавил в расширение роль "Полные права", раскидал объекты по ролям, проверил, изменений нет, ошибка сохраняется.
Обновить вспомогательные данные решил после того, как в расширение добавил свой документ, попытался запустить систему и система сказала, что требуется выполнить операцию обновления вспомогательных данных.
Если кто-то сталкивался или знает как решить это, подскажите, пожалуйста.
Всем заранее огромное спасибо!
При проверке ролей для пользователей приложения найдены ошибки:
Роль "Оперативный отдел" содержит право Изменение неразделенного объекта Справочник.ИдентификаторыОбъектовМетаданных.
Роль "Санитарная бактериология" содержит право Изменение неразделенного объекта Справочник.ИдентификаторыОбъектовМетаданных.
Роль "Право на чтение всех справочников" содержит право Изменение неразделенного объекта Справочник.ИдентификаторыОбъектовМетаданных.
Роль "Полные права" содержит право Изменение неразделенного объекта Справочник.МедицинскиеОрганизации.
Роль "Полные права" содержит право Добавление неразделенного объекта Справочник.МедицинскиеОрганизации.
Роль "Полные права" содержит право Удаление неразделенного объекта Справочник.МедицинскиеОрганизации.
Роль "Полные права" содержит право Изменение неразделенного объекта Справочник.ПодразделенияМедОрганизаций.
И так далее. записей подобных много
скажу так, опытным путем получил следующее - добавил роли, на которые ругается система, в свое расширение и убрал все галки, теперь при запуске обновления вспомогательных данных система на эти роли не ругается, но и не выполняется, говорит - "Ошибки при выполнении функции ОбщегоНазначения.ИдентификаторыОбъектаМетаданных()"
Для объекта метаданных "Справочник.МедицинскиеОрганизации" не найден идентификатор в справочнике "Идентификаторы объектов метаданных" и регистре сведений "Идентификаторы объектов версий расширений".
Ну и соответственно предлагает обновить вспомогательные данные, которые не обновляются.
Замкнутый круг
(4) по ашипке "Ошибки при выполнении функции ОбщегоНазначения.ИдентификаторыОбъектаМетаданных()" гуглится:
Ошибок связанных с правами нет, но есть такая:
: Ошибки при выполнении функции ОбщегоНазначения.ИдентификаторыОбъектаМетаданных().
Для разработчика: возможно требуется обновить вспомогательные данные,
которые влияют на работу программы. Для выполнения обновления можно:
При выполнении всех рекомендуемых системой действий получаю снова эту же ошибку, вот и получается замкнутый круг
(7) так написали уже, что это простейшая ошибка, у меня была неделю назад, вылечил при помощи "Запустить программу с параметром командной строки /С ЗапуститьОбновлениеИнформационнойБазы",
в конфигураторе заходишь в меню Сервис - Параметры, на зкладке запуск 1с предприятия находишь поле "Параметр запуска", туда пишешь
(8) ну нет же, я же написал, что при выполнении всех процедур я ловлю снова такую же ошибку, не помогает /С ЗапуститьОбновлениеИнформационнойБазы
(10) обновление запускается? Чисто визуально следишь за тем как обновление происходит? До конца доходит?
Всем добра и успехов!
Обновляю свою одинэску.
Бухгалтерия предприятия, редакция 3.0 (3.0.40.42)
1С:Предприятие 8.3 (8.3.8.1652)
Установил несколько релизов, стал ставить релиз 3.0.43.100 и теперь столкнулся с проблемой
При проверке ролей для пользователей найдены ошибки:
Роль "ИЛСТ менеджер ЖДПеревозок" содержит недоступное право АдминистрированиеРасширенийКонфигурации.
Роль "ИЛСТ администратор ЖДПеревозок" содержит недоступное право Администрирование.
Роль "ИЛСТ администратор ЖДПеревозок" содержит недоступное право ОбновлениеКонфигурацииБазыДанных.
ВызватьИсключение ЗаголовокОшибки + ТекстОшибки
- Вопрос задан более трёх лет назад
- 994 просмотра
А почему вы не хотите сразу поставить последнюю версию 3.0.49.23 ? Обновитесь не с *.cfu, из файла *.cf - все обработчики с перехода конфигурации от версии к версии все равно будут запущены.
Видимо в промежуточном релизе был глюк по управлению правами, который стреляет на более свежих платформах (ваша 3.0.43.100 разрабатывалась под 8.3.6.2449 и тогда видимо еще не было расширений конфигурации и соответствующих прав). Как вариант можете поставить платформу 8.3.6 и на ней сделать часть обновлений, а потом продолжить уже на вашей 8.3.8.
У меня уже база рабочая, по этой причине приходится накатывать релизы поэтапно. Что касается вашего совета, то если я правильно понял, нужно удалить установленную 1С, потом установить платформу 8.3.6, на эту платформу установить свою базу, накатить релизы (до 43.100) и потом обновить платфрму до 8.3.8 ?
1) Две платформы могут стоять параллельно. Ничего удалять не нужно. В свойстве подключения в списке баз необходимо явно прописать версию платформы, под которой она должна стартовать. Если у вас сервер, то установка другой платформы изменит настройки запуска службы. Потом можно будет восстановить более новую платформу или вообще поставить последнюю из 8.3.9 (8.3.10 говорят прикольная, но там находят мелкие баги)
2) Файлы обновлений *.cfu и *.cf отличаются только размером и тем, что из *.cf можно сделать полностью новую пустую базы. С точки зрения обновления рабочей базы они равноценны. И вы сбережете время на прыжках вежду версиями.
Как понять, каких прав не хватает? Пользователь создает документ Заявка на оплату и когда заполняет контрагента появляется ошибка "Нарушение прав доступа". Права на справочник Контрагенты есть.
- Вопрос задан более года назад
- 984 просмотра
Простой 1 комментарий
Ну есть же полный стек вызова. У пользователя нет прав на создание платежного поручения. Либо вообще, либо по RLS
Посмотрите журнал регистрации. Возможно там указан объект метаданных, который вызывает данную ошибку.
Как вариант включите в отладке "остановка по ошибке" опцию "останавливаться по ошибке". Это поможет увидеть строку где возникает ошибка. Для первичной диагностики проблемы этого должно быть достаточно.
Я вставила скрин из журнала регистрации. "Остановка по ошибке" не поможет, потому что у пользователя нет доступа к конфигуратору.
Xris, давайте по скрину гадать.
Первая строка - создание документа "Платежное поручение". Пользователь может его создать?
Константин Нагибович, да. На создание у него есть права. Ошибка возникает, когда он заполняет поле Контрагент
Скрина недостаточно для диагностики. Тут или типовая конфигурация (тогда проблемы возможно с Договоров и Банковским счетом, к которым нет доступа по РЛС), или дописки и там может быть все что угодно.
Чтобы однозначно разобраться, нужно запустить конфигуратор на отладку и подключится к серверной сессии пользователя. Поставить остановку на процедуру КонтрагентПриИзмененииНаСервере() и далее пошагово идти, пока не поймаете ошибку на обращение к каким-то данным.
Как можно проверить:есть ли у определенного пользователя определенная роль?
Я пишу запрос :
"ВЫБРАТЬ
Пользователи.ПрофильПолномочийПользователя.СоставРолей( ИмяРоли КАК ИмяРоли )
ИЗ
Справочник.Пользватели КАК Пользователи
ГДЕ
Пользователи.Ссылка = &Пользователь " ;
Потом задаю параметр Пользователь.
Запрос.Выполнить.Выгрузить.
Но ничего не выходит
(2) РольДоступна() - проверяет доступность роли для текущего пользователя
Если же надо проверить для другого пользователя, точнее для ссылки на справочник Пользователи то обычно в типовых у этого справочника есть реквизит ИдентификаторПользователяИБ (это в УТ11) либо по по коду/имени надо найти Пользователя ИБ - обратиться к коллекции ролей
ПользователиИнформационнойБазы.НайтиПоИмени().Роли
НайтиПоУникальномуИдентификатору().Роли.Содержит(Метаданные.Роли.ПолныеПрава)
DoctorRoot; maxst22; Kovekh; jane_de_rio; Kuzya_brаtsk; json; Serg_buz; sermalp; itriot11; kanat1; pihy; Afa_fil; adhocprog; Trapezaspb; mailrum2004; + 15 – Ответить
Спасибо! Но теперь у меня возникла другая задача : каждый пользователь имеет полные права.Я создаю роль,кто. изменяет справочник "Номенклатура". Мне нужно после проверки на роль "Изменение номеклатуры" при ее отсутствии запретить изменять номенклатуру.
Т.е
Если РольДоступна("ИзменениеНоменклатуры") Тогда
.
Иначе
запрет изменения номенклатуры
КонецЕсли;
Зачем такие сложности и по тексту программы менять стандартную конфигурацию? Не проще ли (думаю, и правильней) дать пользователю другую роль (не полные права) и ограничить доступ к номенклатуре при помощи механизма ограничения прав доступа на уровне записей?
Для этого вначале указывается настройка параметров доступа на уровне записей (в 1С:Комплексная автоматизация, например, это реализовано через Операции -> Константы -> Настройка параметров доступа на уровне записей. Там устанавливается флаг "Ограничить доступ на уровне записей по видам объектов" -> Номенклатура). Затем настраиваются группы пользователей: должна быть "Без ограничения прав", и в Вашем случае - группа с ограничением на запись номенклатуры. После этого распределите своих пользователей на группы пользователей.
Я попробовала, как вы сказали, у меня пользователь администратор, стоят полные права, галочку в константах я поставила, создала группу ограничения прав, в настройках доступа указала даже конкретную группу номенклатуры, но независимо от того настраиваю ли я или нет этот доступ перезагружая программу всё равно номенклатуру можно изменить. Может я что-то не так делаю? И все-таки можно ли это как-то прописать в конфигураторе?
Вариант 1. Вам придется либо "уйти" от полных прав, создать индивидуальные роли для каждой группы пользователей, у всех созданных ролей убрать доступ к справочнику Номенклатура. Создать роль например "НоменклатураДобавлениеИзменение", у которой будет соответствующий доступ к справочнику Номенклатура, и назначить эту роль тем пользователям, которым необходимо работать с ней.
Вариант 2 (менее правильный ИМХО). Создать роль "НоменклатураДобавлениеИзменение". Прописать в модуле справочника в процедуре ПриЗаписи():
Почему Вариант 2 ИМХО менее правильный. Если вы вдруг переименуете роль, или вообще удалите из конфигурации - получите ошибку при записи справочника. Первый же метод требует бОльших "усилий", зато не приведет к подобным ошибкам
Читайте также: