Ошибка "У пользователя недостаточно прав на исполнение операции над базой данных"
Всем добрый день!
Очень странная ситуация. В базе ведется учет по разным организациям. Права доступа настроены так, что пользователи видят только данные по своей организации. Есть два пользователя из разных организаций, у которых права доступа настроены абсолютно одинаково. Пытаюсь рассчитать средний заработок в документе "Оплата по среднему" (при расчете среднего заработка в отпуске тоже самое) - в одной организации все нормально, в другой не рассчитывается. Ошибка при выполнении запроса. Нажимаю подробно:
{ОбщийМодуль.ПроведениеРасчетовПереопределяемый.Модуль(2433)}: Ошибка при вызове метода контекста (Выполнить)
ВыборкаБазы = Запрос.Выполнить().Выбрать();
по причине:
по причине:
Ошибка выполнения запроса
по причине:
У пользователя недостаточно прав на исполнение операции над базой данных.
Лезу в код. В этом модуле, перед тем, как выполняется запрос, вызывается процедура
ПроведениеРасчетов.ДописатьАлгоритмВЗапрос("РасчетнаяБазаСреднегоЗаработка", КомментироватьРасчет, Запрос);
в которой дописывается кусок запроса, именно в нем проблема. Если закомментировать вызов этой процедуры, запрос выполняется. Проверила доступ ко всем регистрам, справочникам, используемым в этом запросе - с доступом все нормально.
Не понимаю, где рыть!!! Повотрюсь - в других организациях все считается нормально. Только в одной.
Есть еще непонятная ситуация - перепровожу документы "Начисление зарплаты" (все в той же организации). Все документы перепроводятся, а по одному месяцу не проводится. Ошибка при вызове метода контекста (Выполнить):
Ошибка при выполнении обработчика - 'ПриЗаписи'
по причине:
{РегистрРасчета.ОсновныеНачисленияРаботниковОрганизаций.МодульНабораЗаписей(688)}: Ошибка при вызове метода контекста (Выполнить)
по причине:
Ошибка выполнения запроса
по причине:
У пользователя недостаточно прав на исполнение операции над базой данных.
В самом запросе идет затык при попытке выбрать записи:
|ИЗ
| РегистрРасчета.ОсновныеНачисленияРаботниковОрганизаций.ФактическийПериодДействия(
| ВидРасчета В
| (ВЫБРАТЬ
| СписокВР.ВидРасчета
| ИЗ
| ВТ_СписокВР КАК СписокВР)
| И (Сотрудник, ПериодДействия) В
| (ВЫБРАТЬ
| ОсновныеНачисления.Сотрудник,
| ОсновныеНачисления.ПериодДействия
| ИЗ
| ВТ_СотрудникиПериодыДействия КАК ОсновныеНачисления)) КАК НачисленияФПД
Что это за ФактическийПериодДействия и как к нему определяется доступ?
Если бы была проблема некорректной настройки правд доступа в принципе, не думаю, что документы "Начисление зарплаты по сотрудникам организаций" вообще бы проводились. А так, получается, что по всем месяцам проводятся, и только в одном - нет.
А отпуска и оплата по среднему вообще не проводятся. Кто с таким сталкивался? Не знаю, что делать, куда лезть дальше...
Очень странная ситуация. В базе ведется учет по разным организациям. Права доступа настроены так, что пользователи видят только данные по своей организации. Есть два пользователя из разных организаций, у которых права доступа настроены абсолютно одинаково. Пытаюсь рассчитать средний заработок в документе "Оплата по среднему" (при расчете среднего заработка в отпуске тоже самое) - в одной организации все нормально, в другой не рассчитывается. Ошибка при выполнении запроса. Нажимаю подробно:
{ОбщийМодуль.ПроведениеРасчетовПереопределяемый.Модуль(2433)}: Ошибка при вызове метода контекста (Выполнить)
ВыборкаБазы = Запрос.Выполнить().Выбрать();
по причине:
по причине:
Ошибка выполнения запроса
по причине:
У пользователя недостаточно прав на исполнение операции над базой данных.
Лезу в код. В этом модуле, перед тем, как выполняется запрос, вызывается процедура
ПроведениеРасчетов.ДописатьАлгоритмВЗапрос("РасчетнаяБазаСреднегоЗаработка", КомментироватьРасчет, Запрос);
в которой дописывается кусок запроса, именно в нем проблема. Если закомментировать вызов этой процедуры, запрос выполняется. Проверила доступ ко всем регистрам, справочникам, используемым в этом запросе - с доступом все нормально.
Не понимаю, где рыть!!! Повотрюсь - в других организациях все считается нормально. Только в одной.
Есть еще непонятная ситуация - перепровожу документы "Начисление зарплаты" (все в той же организации). Все документы перепроводятся, а по одному месяцу не проводится. Ошибка при вызове метода контекста (Выполнить):
Ошибка при выполнении обработчика - 'ПриЗаписи'
по причине:
{РегистрРасчета.ОсновныеНачисленияРаботниковОрганизаций.МодульНабораЗаписей(688)}: Ошибка при вызове метода контекста (Выполнить)
по причине:
Ошибка выполнения запроса
по причине:
У пользователя недостаточно прав на исполнение операции над базой данных.
В самом запросе идет затык при попытке выбрать записи:
|ИЗ
| РегистрРасчета.ОсновныеНачисленияРаботниковОрганизаций.ФактическийПериодДействия(
| ВидРасчета В
| (ВЫБРАТЬ
| СписокВР.ВидРасчета
| ИЗ
| ВТ_СписокВР КАК СписокВР)
| И (Сотрудник, ПериодДействия) В
| (ВЫБРАТЬ
| ОсновныеНачисления.Сотрудник,
| ОсновныеНачисления.ПериодДействия
| ИЗ
| ВТ_СотрудникиПериодыДействия КАК ОсновныеНачисления)) КАК НачисленияФПД
Что это за ФактическийПериодДействия и как к нему определяется доступ?
Если бы была проблема некорректной настройки правд доступа в принципе, не думаю, что документы "Начисление зарплаты по сотрудникам организаций" вообще бы проводились. А так, получается, что по всем месяцам проводятся, и только в одном - нет.
А отпуска и оплата по среднему вообще не проводятся. Кто с таким сталкивался? Не знаю, что делать, куда лезть дальше...
По теме из базы знаний
- Конфигурация Flowcon: Набор инструментов для управления задачами, проектами и бизнесом в 1С
- Не спеша, эффективно и правильно – путь разработки. Часть 3. Практика
- Автоматическая классификация ошибок технологического журнала
- Цифровая подпись. Документооборот КОРП 2.1
- Подготовка отчетности за 2020 год в условиях ограничений на уровне записей RLS в УПП 1.3
Ответы
Подписаться на ответы
Инфостарт бот
Сортировка:
Древо развёрнутое
Свернуть все
Если бы данная организация не была бы включена, тогда бы все документы не проводились бы. Не? А так, получается:
1. Документы "Начисление заработной платы по сотрудникам организации" проводятся по всем месяцам, начиная с 2009г., и только в марте 2011 не проводится. Так же не могу снять проведение.
2. Средний заработок не считается ни в отпусках, ни в оплате по среднему. Ни в одном документе.
1. Документы "Начисление заработной платы по сотрудникам организации" проводятся по всем месяцам, начиная с 2009г., и только в марте 2011 не проводится. Так же не могу снять проведение.
2. Средний заработок не считается ни в отпусках, ни в оплате по среднему. Ни в одном документе.
"Вам надо будет запустить программу в режиме конфигуратора под именем администратора. Затем нужному пользователю сменить права на "Полный" и все. " Да, и всё, а еще прикупить БОЛЬШУЮ банку вазелина на будущее, когда начальство вами займётся.
По теме вопроса: Скорее всего права доступа к организации оформлены в виде периодического значения (записи в регистре сведений). Не знаю cтруктуры вашей конфигурации, но попробуйте покопать в этом направлении, может быть поможет.
По теме вопроса: Скорее всего права доступа к организации оформлены в виде периодического значения (записи в регистре сведений). Не знаю cтруктуры вашей конфигурации, но попробуйте покопать в этом направлении, может быть поможет.
Не знаю насчет регистра сведений, но, после того, как проставила в текстах запросов "Выбрать разрешенные", при формировании расчетной ведомости, перестал отображаться один вид расчета. Вид расчета вводился через документ "Премии сотрудников организации". Что с ним не так, так и не поняла. Ввела новый, абсолютно такой же, и перевыбрала во всех документах. Хочу при очередном обновлении поубирать все "выбрать разрешенные", может все будет нормально. Если нет, опаять верну.
Я в таких случаях выполняю неработающий запрос в консоли запросов с полными правами и с правами пользователя с выбором разрешенных записей. Потом сравниваю обе выборки и отбираю строки, которые не вошли во вторую выборку. По этим строкам уже ищу причину.
(16) aarty, (17) kksu36, вы, видимо, не понимаете: как только Nata_d пропишет пользователю ПолныеПрава, то ей лучше увольняться, а в перспективе, возможно, и переехать в другой регион - уволят с волчьим билетом. Это ж "распространение конфиденциальной информации" получится - начальство такого на дух не переносит.
У нас клиент договор разорвал за то, что файлик с зарплатой 10 минут в общем доступе был - а вы говорите ПолныеПрава! Программисту после решения проблемы надо ещё гемора на пятую точку не огрести.
У нас клиент договор разорвал за то, что файлик с зарплатой 10 минут в общем доступе был - а вы говорите ПолныеПрава! Программисту после решения проблемы надо ещё гемора на пятую точку не огрести.
Ну вы че?))) Какие полные права?))) Проблема пока не решена. Вчера делала обновление. Затерла все записи "Выбрать разрешенные", думала - а вдруг после обьновления все заработает?))) К сожалению, пришлось опять везде прописать волшебные слова...
у меня просто дает предупреждение "у пользователя недостаточно прав на исполнение операции над базой данных" полномочия на документ ЗаявкаНаНРасходДенежныхСредств и регистры есть, в допправах галки проставлены, что делать как жить дальше?
{ОбщийМодуль.ПроведениеРасчетовПереопределяемый.Модуль(1938)}: Ошибка при вызове метода контекста (Выполнить)
Выборка = Запрос.Выполнить().Выбрать();
по причине:
Ошибка обращения к серверу 1С:Предприятия.
по причине:
server_addr=tcp://SERVER-A:1560 descr=Ошибка сетевого доступа к серверу
(Windows Sockets - 10054(0x00002746). Удаленный хост принудительно разорвал существующее подключение. ) line=794 file=Src\DataExchangeTcpClientImpl.cpp
Выборка = Запрос.Выполнить().Выбрать();
по причине:
Ошибка обращения к серверу 1С:Предприятия.
по причине:
server_addr=tcp://SERVER-A:1560 descr=Ошибка сетевого доступа к серверу
(Windows Sockets - 10054(0x00002746). Удаленный хост принудительно разорвал существующее подключение. ) line=794 file=Src\DataExchangeTcpClientImpl.cpp
Этот запрос пробую проверять в консоли запросов с правами пользователя выкидывает из сеанса. ошибка SDBL соединение с базой данных не удерживает. Отпустить контекст соединение не возможно. При полных правах все нормально.
(33) Nata_d, писать ВЫБРАТЬ РАЗРЕШЕННЫЕ и делать (или продолжать делать) конфу не типовой - не тру!)
У меня клиент на Комплексной автоматизации (далее "КА"), и у него не проводился документ Комплектация номенклатуры (суть не в документе), писал ошибку аналогично Вашей из первом сообщение.
Советую тем кто сталкивается с такой проблемой следовать следующим действия
1) Помнить, шаманства типа - запустить под другой конфой или тестирование сделать - это не катит, Конфа отрабатывает правильно, а вот пользователь настроил не верно.
2) Сразу же как вылезла ошибка, лезем в Журнал регистрации (в КА через Полный интерфейс по кнопке Сервис) и смотрим на какой регистр ругань идёт, записываем название (у меня был ТоварыОрганизаций РегНакопления).
3) В КА через интерфейс "Администрирование пользователей" жмем кнопку "Доступ на уровне записи" -> "Настройка доступа" и проверяем корректность прав пользователя с данными из справочника "Пользователи". Правильная ли выставлена группа доступа у косячного пользователя.
Смотрим какие ограничения в необходимой группе доступа.
У меня было 2-а параметра отбора (ограничения) - Организация и Склад.
4) Далее я делал так, в открытой нами обработке "Настройка прав доступа" выбрал нужную мне группу и начал вычислять где косяк - в Организации или Складе.
Сначала добавил строку в закладку Организации, в которой ничего не указывал по колонке "Объект доступа", т.е. получается, что дал запись и чтение по всем Организациям.
Попробовал провести документ - не получилось.
Удалил ранее созданную строку из настроек прав по Организации и сделал то же самое для Склада. Документ провёлся.
5) Залез в "косячный регистр" ТоварыОрганизации, который получил на "шаге" №2 и увидел чудо! Склад в шапке документа есть, а в регистре, после проведения, отсутствует напрочь!
Полез в настройки учётнойПолитики УУ, и на закладке "Запасы" поставил галочку "Вести учёт МПЗ Организаций в разрезе складов".
Удалил лишнюю строку из "Настроек прав пользователей" и всё заработало.
ИТОГО: Вычисляем косячный регистр, Узнаём поля отбора в "Настройках прав пользователей", Методом проб и ошибок узнаём косячный элемент отбора, И в "искусственно" проведённом документе переходим к данным косячного регистра, В итоге докапываемся до сути (по ситуации).
Я думаю в Зарплатных регистрах это по-сложнее будет, но суть едина.
У меня клиент на Комплексной автоматизации (далее "КА"), и у него не проводился документ Комплектация номенклатуры (суть не в документе), писал ошибку аналогично Вашей из первом сообщение.
Советую тем кто сталкивается с такой проблемой следовать следующим действия
1) Помнить, шаманства типа - запустить под другой конфой или тестирование сделать - это не катит, Конфа отрабатывает правильно, а вот пользователь настроил не верно.
2) Сразу же как вылезла ошибка, лезем в Журнал регистрации (в КА через Полный интерфейс по кнопке Сервис) и смотрим на какой регистр ругань идёт, записываем название (у меня был ТоварыОрганизаций РегНакопления).
3) В КА через интерфейс "Администрирование пользователей" жмем кнопку "Доступ на уровне записи" -> "Настройка доступа" и проверяем корректность прав пользователя с данными из справочника "Пользователи". Правильная ли выставлена группа доступа у косячного пользователя.
Смотрим какие ограничения в необходимой группе доступа.
У меня было 2-а параметра отбора (ограничения) - Организация и Склад.
4) Далее я делал так, в открытой нами обработке "Настройка прав доступа" выбрал нужную мне группу и начал вычислять где косяк - в Организации или Складе.
Сначала добавил строку в закладку Организации, в которой ничего не указывал по колонке "Объект доступа", т.е. получается, что дал запись и чтение по всем Организациям.
Попробовал провести документ - не получилось.
Удалил ранее созданную строку из настроек прав по Организации и сделал то же самое для Склада. Документ провёлся.
5) Залез в "косячный регистр" ТоварыОрганизации, который получил на "шаге" №2 и увидел чудо! Склад в шапке документа есть, а в регистре, после проведения, отсутствует напрочь!
Полез в настройки учётнойПолитики УУ, и на закладке "Запасы" поставил галочку "Вести учёт МПЗ Организаций в разрезе складов".
Удалил лишнюю строку из "Настроек прав пользователей" и всё заработало.
ИТОГО: Вычисляем косячный регистр, Узнаём поля отбора в "Настройках прав пользователей", Методом проб и ошибок узнаём косячный элемент отбора, И в "искусственно" проведённом документе переходим к данным косячного регистра, В итоге докапываемся до сути (по ситуации).
Я думаю в Зарплатных регистрах это по-сложнее будет, но суть едина.
У меня была подобного рода ошибка при запуске отчета пользователем с ограниченными правами.
Ищите в запросе регистр, к которому нет доступа у пользователя, установите права на этот регистр для его роли, поможет.
Проверено 100%.
Спасибо.
Ищите в запросе регистр, к которому нет доступа у пользователя, установите права на этот регистр для его роли, поможет.
Проверено 100%.
Спасибо.
И у меня возникла такая ошибка при проведении документа Начисление зарплаты. У расчетчика право доступа к 1 организации. Полные права отключены. На всех справочниках, документах и регистрах стоит Редактировать и Изменять. Где что еще настроить?!
Мы нашли источник аналогичной ошибки.
У нас БП 3.0 КОРП, используется RLS с ограничением бухгалтеров по отдельным организациям.
Ошибка "У пользователя недостаточно прав на исполнение операции над базой данных" возникала при создании платёжного поручения по НДФЛ копированием старой платёжки. Причём, у некоторых бухгалтеров несколько платёжек создавались нормально, а при попытке создания следующей платёжки возникала ошибка.
Причиной ошибки является некорректная запись в регистре сведений. Нужно найти в каком.
Открываем Журнал регистрации и текущей датой ищем событие "Доступ.Отказ в доступе", получаем записи пользователей с отказом в доступе. Открываем одну запись и видим картинку.
В метаданных видим регистр сведений "Реквизиты уплаты налогов и платежей в бюджет" и несколько справочников. Открываем этот РС через Все функции, делаем сортировку по организации, и видим наверху запись с пустой организацией. Удаляем ошибочную запись.
P.S. Осталось найти, каким образом получилась такая запись в регистре :) .
У нас БП 3.0 КОРП, используется RLS с ограничением бухгалтеров по отдельным организациям.
Ошибка "У пользователя недостаточно прав на исполнение операции над базой данных" возникала при создании платёжного поручения по НДФЛ копированием старой платёжки. Причём, у некоторых бухгалтеров несколько платёжек создавались нормально, а при попытке создания следующей платёжки возникала ошибка.
Причиной ошибки является некорректная запись в регистре сведений. Нужно найти в каком.
Открываем Журнал регистрации и текущей датой ищем событие "Доступ.Отказ в доступе", получаем записи пользователей с отказом в доступе. Открываем одну запись и видим картинку.
В метаданных видим регистр сведений "Реквизиты уплаты налогов и платежей в бюджет" и несколько справочников. Открываем этот РС через Все функции, делаем сортировку по организации, и видим наверху запись с пустой организацией. Удаляем ошибочную запись.
P.S. Осталось найти, каким образом получилась такая запись в регистре :) .
Прикрепленные файлы:
Не смотря на то, что тема от 2011 года, актуальна она до сих пор. Столкнулся с подобной проблемой в конфигурации Рарус Магазин бытовой техники и средств связи, естественно RLS включен и проблема появилась после того как пользователя переместили в другой магазин. Настройки у него все верные, все как надо, но при попытке открыть список приходных ордеров выдавалась такая же ошибка. Причиной оказались настроенные у пользователя фильтры отображения. Сначала возвращаем пользователю старые права, сбрасываем все настройки фильтров, какие нужно, выставляем права и вуаля, ошибки больше нет. Если кто-то знает, как сбросить это все без переключения прав, поделитесь плиз, думаю , еще пригодится.
Такая ошибка выходила при программном обходе документов через свою обработку:
Док.Выбрать()
Док.Следующий()
Причина была в том, что настроены rls по организациям, и в выборку попадали документы по недоступным организациям. Помогла установка отбора в выборке по доступной организации.
Док.Выбрать()
Док.Следующий()
Причина была в том, что настроены rls по организациям, и в выборку попадали документы по недоступным организациям. Помогла установка отбора в выборке по доступной организации.
Как я понял, при возникновении ошибки доступа, вызванной RLS в журнал регистрации не пишется название объекта, к которому нет доступа (типа регистр сведений такой-то или справочник такой-то). Очень проблематично искать причину, если используется сразу несколько ограничений: по организации, по подразделению, по складам и т.п. Если кто знает, как определить, каким ограничением RLS вызван отказ доступа, поделитесь пожалуйста.
Поделюсь своим опытом. Временно, как аварийное решение, в подобных проблемах иногда помогает такой ход: создается условная роль "Полное чтение" в которой прописывается право чтения на все объекты базы, эта роль присваивается "проблемному" пользователю, затем, пока пользователь работает на таком костыле, ищется и устраняется истинная причина появления ошибки.
Для выборки данных
Способ со 100% гарантией
Находите процедуру, в которой непосредственно выполняется запрос к данным.
Добавляете её в расширение со свойством "Вызывать вместо (с контролем)".
(В расширении можно сделать роль, чтобы давать её только нужным пользователям через группы доступа.)
В самом начале процедуры делаете вставку с установкой привилегированного режима.
И никаких полных прав не потребуется.
Например, для типового отчета:
Способ со 100% гарантией
Находите процедуру, в которой непосредственно выполняется запрос к данным.
Добавляете её в расширение со свойством "Вызывать вместо (с контролем)".
(В расширении можно сделать роль, чтобы давать её только нужным пользователям через группы доступа.)
В самом начале процедуры делаете вставку с установкой привилегированного режима.
И никаких полных прав не потребуется.
Например, для типового отчета:
&ИзменениеИКонтроль("ПриКомпоновкеРезультата")
Процедура рев_ПриКомпоновкеРезультата(ДокументРезультат, ДанныеРасшифровки, СтандартнаяОбработка)
#Вставка
УстановитьПривилегированныйРежим(Истина);
#КонецВставки
// типовой код
КонецПроцедуры
Показать
Есть еще вариант решения данного бага RLS. Если используется Производительный вариант работы, то надо переключить на Стандартный. В журнале регистрации вообще была запись об отсутствии доступа на чтение к документу. При этом пользователь, естественно, не только имел доступ на чтение этих документов, но и на запись с проведением.
Прикрепленные файлы:
Для получения уведомлений об ответах подключите телеграм бот:
Инфостарт бот