Недостаточно прав для создания 1с

Обновлено: 03.07.2024

Текст ошибки говорит сам за себя. Разделим его на 2 части: первая — « нет прав », вторая связана с « видом клиента », т. е. режимом запуска.

Это уведомление появляется в процессе входа в информационную базу 1С. Когда вы уже ввели свои имя пользователя и пароль.

При попытке открытия базы программа проверяет ваши полномочия (права) и отказывает, если вашему пользователю явно не разрешен тип клиента, с которого вы входите.

Закономерный вопрос, даже два:

Где находятся эти разрешения и как их настроить?
Какие типы клиентов бывают? — для проверки входа в другом режиме.

Если конфигурация типовая

откройте 1С в режиме «Конфигуратор», войдите в меню « Администрирование — Пользователи », в списке выберите пользователя, у которого возникает ошибка;
нажмите « Изменить », на вкладке « Прочее » назначьте необходимые роли и сохраните изменения.

Если конфигурация своя (нетиповая)

Возможно, в созданных ролях не указан тип запуска. Также зайдите в «Конфигуратор» и проверьте созданные роли. В ролях устанавливается разрешенный режим запуска различных приложений.

✅ Как видите, всё дело в правах. Причина в том, что у пользователя нет минимального набора прав для запуска программы.

Поэтому, первым делом проверьте какие полномочия установлены для учётной записи пользователя.

Варианты запуска программы 1С

📝 Всего — четыре, отличаются принципом работы и требовательностью к ресурсам ПК, на котором работаете. Рассмотрим подробнее.

1. Толстый клиент

Наиболее требовательный к ресурсам рабочей машины, поскольку обработка данных выполняется на компьютере пользователя. Здесь же хранятся необходимые для работы файлы.

Не зависит от Интернета, не представляет возможности удалённой работы. Для запуска толстого клиента используется файл 1cv8.exe .

2. Тонкий клиент

Представляет программную оболочку для доступа к серверу 1С. Привычный интерфейс меню и настроек, но, поскольку обработка происходит на сервере, не требователен к мощности оборудования.

Пользователю предоставлен ограниченный функционал, возможна работа как с удалённым сервером через Интернет, так и на самом компьютере в специальной программной среде. Запуск тонкого клиента выполняется файлом 1cv8c.exe .

3. Веб-клиент

Для работы понадобится веб-браузер и Интернет-соединение. Нет привязки к месту работы. Нагрузка на оборудование минимальная, так как вычисления происходят на удалённом сервере. Веб-клиент системы 1С функционирует под управлением браузера.

4. Конфигуратор

Специальный режим для тонкой настройки программы, работающий только при использовании толстого клиента.

Если у вас не получается настроить роли, проверьте каким образом вы открываете приложение 1С. Возможно, вы запускаете не « 1cestart.exe », а открываете напрямую приложение 1cv8.exe (толстый клиент).

Выберите ярлык 1С, нажмите правую кнопку мыши и откройте «Свойства». На вкладке « Ярлык » в поле «Объект» поменяйте название запускаемого приложения на 1cv8c.exe (тонкий клиент), нажмите «ОК».

Если открывается менеджер 1cestart

Попробуйте принудительно в свойствах подключения к ИБ установить необходимый вам режим, сняв признак «Выбирать автоматически».

При записи нового документа:
недостаточно прав для выполнения операции
обратитесь к администратору
объект: (внутренний документ)
право: добавление

Куда копать?
В политиках доступа поставил редактирование, в правах на папки тоже, в самом документе в рабочей группе пользователь добавлен.
Получилось сделать через специальные разрешения, но это не то. Почему по умолчанию не работает?

(1) Дмитрий, добрый день!

Попробовал смоделировать Вашу ошибку, не удалось.

Что использовал для моделирования:

Платформа 8.3.9.2170
Конфигурация ДО 2.1.10.2
Файловый вариант

Создал новую базу. Пользователь "Администратор" с полномочиями "Администратор" добавился в процессе начального заполнения данных.

Добавил пользователя: "Пользователь" с полномочиями "Работа с входящими и исходящими документами".

От имени Администратора, создал новый вид внутреннего документа, заполнил только наименование, остальные настройки оставил по умолчанию.

От имени Пользователя создал новый внутренний документ. Папку для него создал в момент создания этого документа. Записал закрыл. Ошибок не было.

От имени Администратора, создал новый вид исходящего документа, заполнил только наименование, остальные настройки оставил по умолчанию.

От имени Пользователя создал новый исходящий документ. Заполнил наименование, заполнил реквизит "Получатель" созданный в процессе создания документа. Записал закрыл. Ошибок не было.

Дмитрий, Вы не могли более подробно описать последовательность и состав действий, чтобы данную ошибку удалось смоделировать?

(3)Создал под админом новый вид внутреннего документа - тест (политики доступа - все пользователи - редактирование) , пользователь этот документ не видит!
Пробую создать папку пользователем нет прав. Добавил права на папку "договорная документация". Под пользователем создал папку тест. Записать внутренний документ нельзя нет прав!

Вложил скрин прав пользователя. Разве этого недостаточно?
Где можно скачать ПОНЯТНОЕ видео по правам в ДО?

(7) Дмитрий, к сожалению, по Вашему скрину мне не понятно, что не так. На чистой и типовой пробовали? Ошибка с правами возникает?

Про видео не подскажу, мне коллега объяснял как система прав устроена в ДО.

(1) Была аналогичная проблема.
У пользователя должны права на редактирование для всех разрезов доступа в политиках доступа, для которых идет запись документа.
Т.е. если, например, есть разрез доступа по организации и у пользователя нет права на редактирование по организации в документе, то документ не запишется. (1) а галочка в рабочей группе стоит напротив этого пользователя? (1) Дмитрий, во-первых, попробуйте в полномочиях поставить еще чек-бокс "Делопроизводители". Во-вторых, не очень понятно, если вы пытаетесь работать с входящими и исходящими документами, то почему же ошибка "Объект "Внутренний документ"? (1) Проверьте в виде документа галочку "Автоматически вести рабочую группу".

Точно такая же проблема.
Всё перелопатили, поназначали где-то только смогли найти права - результата ноль.

Начал копать дальше. Установил демо версию чтобы проверить как разработчики подразумевали работать со своим детищем. И что я вижу - у всех пользователей куча назначенных прав. Нет ни единого у которого просто права пользователя. Оставил права доступа только "Пользователь" - и естественно на демоверсии записать внутренний документ не смогли. НУ НЕ ВСЕ ПОЛЬЗОВАТЕЛИ У НАС РУКОВОДИТЕЛИ ОТДЕЛОВ ИЛИ АДМИНИСТРАТОРЫ.

Пришлось открывать конфигуратор и что я вижу - функция, которая проверяет права доступа к объекту "ПолучитьПраваПользователейПоОднотипнымОбъектам()" запросом проверяет доступ пользователя к документу (по так называемому дескриптору), НО ДОКУМЕНТА В БАЗЕ ЕЩЕ НЕТ, ОН ТОЛЬКО ДОБАВЛЯЕТСЯ! Естественно функция возвращает пустой набор прав и запись произвестись не может. Такое поведение и на 2.1.9 и на 2.1.10. Добавить могут лишь те пользователи у которых до этой проверки не доходит. Админы например.

Покупку этого чуда под названием "Документооборот" остановили (надеюсь и внедрение тоже), ибо это уже просто хамство - продавать бета-версии.

1. Права доступа.
Такой реализации не встречал ни где и ни в одной программе. Всё раскидано по всем возможным разделам. Там можно выбрать группу пользователей там нельзя, там выбирается роль, там пользователь и т.д. и т.п. Отстроить нормальные права доступа это еще та задача.
Сами права обновляются медленно, при увеличении количества документов, вообще боюсь ляжет на нашем сервере.

Прошо 4-е года, а пациенту стало только хуже, на 1.3 из коробки хоть как-то работало, криво меделенно, с "такойто-матерью", но работало.
Я еще пытаюсь отсроить права доступа, если у вас что-то получиться, то просьба отписаться здесь. И соответственно если я что-то смогу настроить (без кодинга), я тоже отпишусь.

Настройка прав доступа - одна из самых распространенных задач для разработчиков 1С. Это не значит, что подобные задачи всегда ставятся явно. Большая часть из них связаны с текущей разработкой, ведь новый функционал требует ограничений на использование среди пользователей. Но есть и исключения, когда поступает заказ / задача по ограничению доступа к некоторым данным или функциям в информационной базе.

Очень часто можно столкнуться с ситуацией, когда после "горячего" внедрения новой системы у большого количества пользователей имеются полные права. То есть пользователей с возможностями администратора информационной базы слишком много. Как результат - множество ошибок в данных, коллизии в настройках учета, странное поведение системы и непредсказуемые результаты отчетов. Великолепно, не правда ли?

Есть и другие истории, когда с правами все в порядке. Есть толковый администратор, который следит за корректностью их настройки. И все работает какое-то время, пока в дело не вступают разработчики (штатные или с аутсорсинга, не важно!). Множество задач, множество требований, множество ошибок с правами. Такова печальная картина.

Конечно, я дал немного пессимистичную оценку, чтобы подготовить Вас к незабываемому путешествию по типичным ошибкам разработки прав доступа. Мы пройдемся по самым частым проблемам, с которыми приходилось сталкиваться. Это не полный список, поэтому Ваши истории также приветствуются в комментариях.

Обычный процесс разработки

Прежде чем перейти непосредственно к ошибкам, давайте вспомним обычный процесс разработки прав доступа. Все основные настройки доступа выполняются с помощью ролей. Роли - объекты конфигурации, занимающие центральное место в построении модели этих самых прав. Именно с их помощью разработчик может настроить доступ к объектам конфигурации. Они же применяются для более гибкой настройки с помощью разграничений на уровне записей (RLS).

Именно с помощью ролей можно добиться приемлемого результата в части разграничений доступа, но не всегда. Если стандартных возможностей этого объекта недостаточно, то в дело вступают различные дополнительные функции, которые добавляют сами разработчики: регистры дополнительных прав, различные запреты с помощью подписок на события и многое, многое другое.

Поскольку мы говорим о самых частых ошибках, то упор будет делаться именно на роли, т.к. именно они являются самым универсальным и простым решениям для большинства задач по правам.

Внезапные проблемы

Итак, поехали! Какие же ошибки могут быть с правами доступа при разработке?

Просто новый объект

Представьте, что к Вам поступил заказ от клиента: создать новый документ в системе для внесения некоторого пакета документов. Другими словами, нужно добавить документ, который хранит ссылки на другие документы и т.д. Задача ясна. День разработки, после демонстрация клиенту (проверял сам директор!) и можно выкладывать в рабочую систему. Перед обновлением сделаны рассылки, что новый функционал заработает с такого-то числа. Наступает день "икс", Вы вечером обновляете базу и с чувством выполненного долга уходите на сон.

Но утром Вас ждет сюрприз! Никто, кроме директора и системного администратора (да, да! он там главный по 1С) не могут получить доступ к новому документу. В интерфейсе его просто нет!

Догадались в чем дело? Ну, конечно! Новый документ добавлен, функционал отлично разработан, но права на него никто не предоставил.

Следовать лозунгу: "Добавил объект - проверь права!".

А еще лучше - написать Unit-тест, который будет проверять объекты без прав доступа. Посмотрите в сторону

Давать права с разумным подходом.

В типовых конфигурациях давно есть разграничения по профилям доступа, группам доступа. С их помощью можно настраивать права быстро и эффективно.

При добавлении новых объектов не стоит делать ставку на роль "Полные права". Нужно либо добавлять новый объект в существующие роли, либо добавлять новые роли. Все же очевидно.

Скроем подсистему

Пришла срочная задача - нужно части пользователей скрыть подсистему "Супер подсистема увеличения продаж".

Проблема в том, что конфигурация наполнена legacy-кодом, а роли конфигурации не имеют четких ограничений между подсистемами. Все связано как какое-то спагетти. А сделать надо еще вчера (ну, Вы понимаете)!

Выпив 3 кружки кофе, решение приходит само. Нужно лишь скрыть всем ролям доступ к этой подсистеме. Именно подсистеме как объекту конфигурации, а все входящие в ее состав объекты вообще не трогать. Только не забыть дать доступ к этой подсистеме для нужной роли (ее даже можно создать отдельно ради такого случая). Гениально!

Есть еще другой путь - доступ на подсистему не менять, а изменить видимость по умолчанию в настройках.

Это будет работать. У вас даже могут принять работу, и Вы разойдетесь с заказчиком рукопожатием. НО! Вы сделаете не разграничение прав доступа, а лишь измените видимость элементов интерфейса. Да, в первом случае доступа к объекту подсистемы не будет, но к объектам из его состава - пожалуйста! Например, в подсистеме был документ "СекрентныйДокумент". Вы идете вот сюда, нажимаете "Перейти по навигационной ссылке" и вводите примерно такую строку.

Имя документа должно быть таким же как в конфигураторе, тогда все сработает. Все! Список документов, доступ к которым нам ограничили, мы открыли. А дальше работаем как нам нужно.

Вариант с настройкой видимости подсистемы еще проще: заходим в настройки интерфейса и включаем видимость для нужной подсистемы.

Как оказалось, права доступа мы и не настроили.

Для того, чтобы не столкнуться с такой ситуацией достаточно запомнить, что настройки видимости подсистем и настройки видимости на объекты подсистемы - это не права доступа. Это лишь ограничения / настройки интерфейса. А ограничивать доступ к данным с помощью интерфейса - это последнее дело при разработке.

Реквизит больше недоступен

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

"Это так круто!", можно услышать от некоторых разработчиков. Действительно, поставил нужные чек боксы и вперед - задача решена!

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

А если данные таким способом можно прочитать, то о каком разграничении доступа может идти речь.

Не используйте эти настройки для решения задач с правами доступа. Это интерфейсные функции.

Для разграничения доступа на изменение реквизитов Вы можете использовать проверки заполнения, события объектов (перед записью, при записи, обработка проведения и др.), в которых реализуете проверки программно. Запретить же просмотр отдельных реквизитов объекта эффективно практически невозможно. Только если дорабатывать все возможные формы, отчеты и другие места конфигурации, добавляя проверки на доступ к нему. Но вот сопровождать такое я бы не взялся.

Есть другой эффективный способ - вынести реквизит в отдельную таблицу и настраивать доступ на нее. Но это уже совсем другая история.

Видимость команд

Выше мы настраивали видимость подсистем. Как уже было сказано, решать так задачи с правами смысла нет, т.к. права на самом деле и не изменяются. По такому же принципу часто поступают не с подсистемами целиком, а с отдельными командами или объектами.

Как и в прошлый раз, по умолчанию пользователь не будет видеть команды в интерфейсе. Но что ему мешает сделать так.

Фиаско? Еще какое!

Повторюсь: настройка видимости и настройка прав доступа - совершенно разные вещи. Никогда не пытайтесь решить вопросы прав доступа с помощью настроек интерфейса.

Новая роль

Выстроенная ролевая модель, четкое разграничение прав доступа. грамотно настроенный RLS! Ваша система эталон работы с правами. И оно понятно, ведь информация в ней чувствительная, ведь это отдел казначейских операций. Сотрудники одного отдела не должны видеть операции соседних подразделений и наоборот. В общем, безопасность на высшем уровне!

Но вот однажды, выпуская новую задачу в рабочую базу, что-то пошло не так! После обновления ВСЕ пользователи стали видеть все заявки, хотя изменения в существующие правила RLS никто не вносил. Что же произошло?

Как Вы догадались - была добавлена новая роль. Нет нет, роль имеет настройки доступа только для тех объектов, для которых действительно нужно. В том числе и для объектов с той самой чувствительной информацией. Вот только есть одна проблема: при добавлении новой роли никто в ней не описал правила RLS, в итоге он перестал работать для всех кому эту роль добавили (в нашем примере ее, допустим, добавили большинству сотрудников).

Как известно, пользователь получает максимальный доступ, который ему предоставляют роли. В нашем случае роль без RLS дает больше прав, чем остальные. Вот платформа их и применяет.

Как же такое вообще можно предотвратить?

Вообще, если в системе есть RLS, то это дополнительная ответственность для разработчиков:

Нужно корректно писать запросы
Необходимо учитывать это в отчетах
При добавлении ролей нужно добавлять правила RLS (это как раз наш случай)
Некоторый код не будет работать с RLS совсем (например, некоторые приемы с объектной техникой работы с данными, или вложенные подзапросы большой глубины и т.д.).
И др.

Так что тут можно посоветовать быть более внимательным и писать Unit-тесты для проверки прав доступа.

RLS не наша тема

Информация выше Вас напугала и теперь использовать RLS никогда не будете? Есть способ проще! Можно в динамических списках, отчетах и других местах подбора данных программно устанавливать отборы на получаемую информацию. Например, добавить ограничения по организации. Вот такой код в событии "При создании на сервере" решает эту задачу.

И ведь все работает! Но раз уж этот подход попал в статью, значит не все так гладко. Проблема в том, что ограничения доступа к данным здесь нет, есть только интерфейсные ограничения. Этот подход еще можно назвать как "костыльный RLS". Его обычно применяют, когда задачу надо сделать еще месяц назад, а в ИТ-отдел уже ломятся сотрудники с требованием ограничить доступ.

Проблема в том, что есть множество других путей получить доступ к этим данным. Предусмотреть все возможные ограничения с помощью программных "костылей" невозможно. Например, пользователь вывел отчет, а в него попал "запретный" документ. Ничто не мешает нам его открыть. Слышу вопрос: "Так в форме документа тоже можно сделать программную проверку при открытии!?". Конечно можно! Но что мне мешает в отчете вывести интересующие меня данные из документа с помощью СКД.

Все защиты пали! А как жаль, ведь потрачены десятки часов работы.

И опять, все это интерфейсные настройки. Зачем заниматься этим, если нужно ограничивать права доступа?

Сроки горят? Отлично, "костыль" оправдан! Только не забудьте вернуться к этому вопросу в будущем.

Я сам настрою

И на последок еще один небольшой "фейл". Иногда в системе имеется дополнительный функционал настройки доступа. Например, регистр сведений "Дополнительные права", в котором каждому пользователю добавляются отдельные функции.

Не раз приходилось сталкиваться с такой ситуацией, что права все настраиваются и все работает. Гибкие настройки - мечта администратора и все такое. Но.

У пользователей тоже есть доступ к этому регистру! Причем у всех и на изменение. Да, этот регистр может быть не выведен явно в интерфейс, но это не гарантия того, что любопытные коллеги будут исследовать информационную систему и найдут эту пасхалку. А раз так, то выдать им себе дополнительные права не составит проблем.

Вывод простой: создавая инструменты управления доступом, не забудьте разграничить доступ на этот инструмент.

На самом деле

Это далеко не полный список потенциальных ошибок. Скорее это самые простые, распространенные и банальные ситуации. Возможно, Вы уже знакомы с некоторыми из них. Какие-то допускали Ваши коллеги, какие-то коллеги коллег, но точно не Вы!

Скажу Вам по секрету, только никому не рассказывайте: за все время работы с платформой 1С и решениями на ее основе автором были сделаны все перечисленные ошибки. И даже больше!

Но если бы не было ошибок, то и опыта бы не было. А также этой публикации :)

Сразу скажу, что, возможно, это боян и все об этом знают 1000 лет и используют, но я не нашел на Инфостарте упоминаний о подобном решении. Так же опережу тех, кто будет говорить о регламентах и автотестировании, все это не дает 100% гарантии отсутствия ошибок, а лишь уменьшает их вероятность и шанс, что вас затронет эта ошибка, все равно есть.

Теперь к описанию проблемы: Рассмотрим типичную ситуацию: разработчик поместил в хранилище новый объект из своей базы, а дать права нужным пользователям на этот объект забыл. В итоге мы можем получить ошибки, связанные с тем, что пользователям в рабочей базе после обновления, даже тем, для кого этот функционал и не предназначался, будут сыпаться ошибки о то, что у них не хватает прав.

Обычно такую проблему решают следующими способами:

Повторным обновлением. Дали по шапке автору проблемы, уведомили бизнес и обновили. Есть проблема: на некоторых предприятиях автомобили загружаются и разгружаются раз 5-10 мин и остановка базы для обновления вне регламентного периода - это ЧП, простои, очереди, штрафы и прочие прелести. К тому же, на некоторых предприятиях установлены SLA и их нормативы не позволят вам остановить базу.
Динамическое обновление. Мы можем обновить базу динамически, т.к. реструктуризации нам не требуется, меняется только роль. Но у динамического обновления есть и свои минусы: возможные проблемы с доступностью и целостностью базы, проблемы с пользовательских и серверным кешем, возможные проблемы обменов РИБ, в связи с различием версий конфигурации.
Временное присвоение пользователям административных прав. Решение рабочее, но все мы понимаем, чем выстлана дорога в одном крайне неприятном направлении, где пахнет серой и довольно жарко. Скажем прямо, решение очень не однозначное. Применять его можно только для доверенных и ответственных пользователей.

Есть и другое решение. Оно довольно очевидно, но его довольно редко применяют. Или может просто мне так не повезло. Если это так, то уберу публикацию в архив и посыплю голову пеплом :)

Суть метода в том, что мы просто добавляем новую роль, в которой отключаем все права, которые в ней будут при создании, при этом устанавливаем флаги "Устанавливать права для новых объектов" и "Устанавливать права для реквизитов и табличных частей по умолчанию". Что нам это даст. У этой роли будут максимальные права, но только на вновь созданные объекты конфигурации и мы в случае проблем с недоступностью объектов сможем без опасений дать пользователям эту роль на период, пока ошибка не будет исправлена. За пределы новых объектов они все равно выйти не смогут. Роль будет автоматически собирать в себя максимальные права для новых объектов, нам нужно только периодически ее очищать от них. Вот такая хитрость.

Читайте также: