Права доступа в ERPNext: роли, уровни прав и доступ к полям без путаницы

Права в ERPNext строятся в три слоя: роль определяет действия над документом, User Permission ограничивает записи, Permission Level закрывает отдельные поля. Ниже: как это настроить для должностей, матрица для девелопера на 26 мест, возможности v16 и типичные ошибки.

Права доступа в ERPNext: три уровня, роль, запись и поле

Когда спрашивают, как в ERPNext «настроить права», обычно смешивают три разных механизма. Первый — роль на тип документа: что пользователь может делать с заявкой, заказом или счётом в целом. Второй — ограничение по записям: видит только свой проект, свой склад или свою компанию. Третий — права на отдельные поля: кто видит цену закупки в документе, который в остальном открыт. Путаница возникает, когда одну задачу пытаются решить механизмом другого уровня.

По документации Frappe, Role Permissions Manager — инструмент, где по умолчанию заданные права ролей можно просмотреть и переопределить. User Permissions ограничивает доступ к документам по значению связанного поля для конкретного пользователя. Permission Level группирует поля так, что отдельные правила применяются к каждой группе; по умолчанию все поля на уровне 0. Эти три механизма работают вместе, и порядок проверки полезно держать в голове: сначала роль, затем записи, затем поля.

Важное правило: User Permission только сужает права. Если у роли нет базового доступа к документу, никакое ограничение по проекту доступ не создаст. Для девелопера, у которого прорабы ведут свои объекты, это значит: сначала выдаёте роли право на заявку, потом ограничиваете пользователя его объектами. Как мы внедряем ERPNext под ключ с настройкой ролей, описано на странице ERPNext под ключ.

Порядок цепочки для читателя, который собирает схему: запрос пользователя, проверка роли на тип документа, фильтр User Permission по записям, проверка Permission Level по полям, в v16 дополнительно маскирование данных. Этот порядок продублирован в инфографике ниже, чтобы вы могли использовать его как опору при диагностике.

Если вы привыкли к модели прав в 1С, переучиваться придётся в одном: в ERPNext права привязаны к типу документа и роли, а не к «профилю доступа» с галочками на объекты метаданных. Для сравнения подходов у нас есть материалы про матрицу доступа в 1С и безопасность прав и аудит в 1С: логика RBAC общая, детали разные.

Role Permissions Manager: Read, Create, Write, Submit, Cancel, Amend и особые права

Открывается менеджер ролей в разделе пользователей и прав. По документации, набор типов прав такой: Read, Write, Create, Delete, Submit, Cancel, Amend, а также Import, Export, Print, Email, Report, Share и Select. Create и Write разделены: можно разрешить прорабу обновлять заявку, не давая создавать новые, и наоборот. Submit, Cancel и Amend настраиваются отдельно и важны для документов, которые «проводятся».

Право Select разрешает выбирать документ в выпадающем списке Link-поля, но не открывать карточку и не читать содержимое. Это удобно для справочников: сотрудник должен выбрать значение, например контрагента или объект, но не видеть реквизиты. Отдельно можно запретить Export, Print, Email и отчёты. Для финансовых документов я почти всегда отключаю Export у всех, кому он не нужен по работе.

Флаг If Owner (в интерфейсе v15 подпись «If user is the owner») ограничивает правило только теми документами, которые создал сам пользователь. Здесь ловушка: если роли не дали право Create, флаг If Owner лишает пользователя доступа ко всем записям, потому что «своих» документов у него по определению нет. Симптом — пользователь жалуется, что список пустой.

Моё правило для небольших команд: не усложнять. Для компании на 26 человек хватает 5–7 ролей и 4–5 должностей, и матрица умещается на одной странице. Лучше пересмотреть её раз в квартал, чем собирать «идеальную» схему на тридцать ролей, которую никто не поддерживает.

Ошибка новичка — выдавать права «временно» через роль System Manager. Временно становится постоянно, и через полгода у половины сотрудников доступ к настройкам системы. Если нужно срочно дать доступ, создайте отдельную роль и запишите в регламенте, когда её надо снять.

• Read и Select — просмотр и выбор значения; Select не открывает карточку.
• Create и Write — разные права, прораб может править без создания.
• Submit, Cancel, Amend — отдельные права для проводимых документов.
• Export, Print, Email, Report — отключайте для финансовых данных.
• If Owner без Create — пустой список у пользователя.

Role Profile: как собрать роли в должность и не раздавать права вручную

Role Profile — шаблон должности: набор ролей, который назначают пользователю одним действием. По документации ERPNext, это способ не выдавать роли по одной при каждом найме; пример из документации — профиль руководителя продаж из нескольких ролей. Создаётся в разделе пользователей и прав. Для девелопера логичны профили «Прораб», «Снабженец», «Бухгалтер», «Руководитель проекта».

Особенность: роли с русскими названиями, которые вы создаёте сами, не системные. Готовых настроек для них нет, и матрицу прав вы настраиваете индивидуально, а не ждёте, что она появится от одного названия. Системные роли ERPNext называются по-английски (например, Purchase User, Stock User), и у них есть готовые права на стандартные документы. Выбор: опереться на системные роли и добавить свои, либо собрать свои с нуля. Я обычно беру системные для типовых действий и добавляю одну-две свои для специфики.

Role Profile упрощает приём и увольнение. Новому прорабу назначаете профиль, и он сразу видит нужные заявки. Когда должность меняется, меняете профиль, и права обновляются без ручной правки. Единственное, что надо помнить: при изменении состава профиля проверьте, что у уже назначенных пользователей роли обновились; поведение синхронизации проверьте на своей версии.

Практический совет для ведения: храните список профилей и ролей в одном документе вместе с датой и ответственным за изменение. Через год вы сами не вспомните, зачем создали роль «Прораб-2».

Permission Level: как скрыть поле от одной роли и не сломать форму

Permission Level — число, которым помечают поле, чтобы ограничить доступ к нему отдельным правилом. По документации, поле с уровнем 1 доступно только роли, у которой в менеджере прав есть строка с уровнем 1. Пример из документации ERPNext: в заказе Customer, Items и Delivery Date остаются на уровне 0, поле Approved Discount вынесено на уровень 1, а Management Remarks на уровень 2. Менеджер по продажам с правом уровня 1 видит и правит скидку, пользователь только с уровнем 0 — нет.

Для девелопера типовой случай — цена закупки в заявке и заказе. Прораб должен видеть позицию и количество, но не закупочную стоимость. Поле «Цена» получает уровень 1, роль прораба остаётся с уровнем 0. Руководитель получает строку уровня 1 с правом Read или Write. Как это выглядит на практике: в заявке прораба поле просто отсутствует, а форма остаётся целой.

Типичная ошибка: при добавлении правила для уровня 1 или 2 система выдаёт ошибку, если у роли нет строки уровня 0 на тот же DocType. Это не настройка, а проверка в коде Frappe (функция check_level_zero_is_set при сохранении прав): права уровня 0 должны быть заданы раньше более высоких уровней. Поэтому порядок всегда такой: сначала базовое право, потом ограничение полей.

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

Версия 16: маскирование данных и свои типы прав

В v16 появились два новых механизма. Первый — маскирование данных. По документации Frappe, оно включается флагом Mask на поле в DocType или в Customize Form, а пользователь без права mask на это поле видит замаскированное значение. Пример из документации: телефон показывается как 811XXXXXXX. Применимо к 14 типам полей: Select, Read Only, Phone, Percent, Password, Link, Int, Float, Dynamic Link, Duration, Datetime, Currency, Data и Date.

Оговорки обязательны. Документация прямо называет функцию экспериментальной и доступной в v16, то есть в v15 её нет. Маскирование не применяется автоматически к своим SQL-запросам и отчётам на сыром SQL: разработчик должен добавить его вручную. Для вашей версии проверьте поведение на тестовой базе до продуктива, а в v15 используйте Permission Level.

Второй механизм — Custom Permission Types, возможность v16. По документации, они создаются в режиме разработчика, проверяются в коде через frappe.has_permission() и назначаются ролям в менеджере прав. Пример из документации: право approve, проверка frappe.has_permission(doc, 'approve'). Это полезно, когда нужно отделить «согласовать» от «изменить». В v15 и ниже такого нет.

# проверка пользовательского права (v16, проверьте в своей версии)
if not frappe.has_permission(doc, "approve"):
    frappe.throw("Нет права согласовывать")

Практический вывод: для проекта на v15 строите схему на Permission Level и роли, для v16 можно дополнить маскированием, но не опирайтесь на него как на единственную защиту. Какую версию мы ставим и как планируем обновления, объясняю на встрече.

Матрица ролей для «Усадьба Групп» на 26 рабочих мест

Условный пример, цифры вымышленные. Девелоперская компания «Усадьба Групп» ведёт несколько жилых проектов, в штате 26 человек: прорабы, два снабженца, руководители проектов, бухгалтер и директор. Задача: прораб подаёт заявки, но не видит цены; снабженец создаёт заказы; бухгалтер видит счета и цены; руководитель проекта согласует.

Матрица для четырёх ролей: | Роль | Заявка на материалы | Заказ поставщику | Счёт поставщика | Цена закупки (уровень 1) | |---|---|---|---|---| | Прораб | Create, Write | нет доступа | нет доступа | скрыта | | Снабженец | Read, Write | Create, Write | Read | Write | | Руководитель | Read, согласует | Read, Submit | Read | Read | | Бухгалтер | Read | Read | Read, Submit | Read |

К матрице добавлен User Permission по проекту: прораб видит только заявки своих объектов. Для этого ему назначается значение проекта, а базовая роль остаётся с правом Create и Write на заявку. Руководитель проекта получает несколько проектов. Бухгалтер ограничений по проектам не имеет, но Export у него включён только на счёта.

Что получилось в примере: прораб создаёт и правит заявку, не видя закупочных цен; снабженец работает с заказом; бухгалтер видит счёт и цену. Я проверил бы матрицу под каждой ролью с настоящим логином, а не под администратором, потому что именно там вылезают пустые списки и скрытые обязательные поля. Для примера путь прошёл быстро, но у вас будут исключения, и их надо записать в регламент.

Типичные ошибки: Custom DocPerm, самосогласование и отмена через Workflow

Симптом, причина, действие. Первое: пользователь потерял все записи после флага If Owner. Причина — у роли нет права Create. Действие: снять флаг или дать Create. Второе: ошибка при выдаче права на Permission Level 1. Причина — у роли нет строки уровня 0, это проверка в коде Frappe. Действие: сначала задать уровень 0.

Третье: после обновления стандартные права не вернулись или изменились не так, как ожидали. Причина — Custom DocPerm: когда вы правите права в Role Permissions Manager, ваши правила записываются как пользовательские и не получают изменений стандартных прав при апгрейде. Действие: после обновления проверять матрицу и вести журнал отклонений.

Четвёртое: самосогласование. Если инициатор имеет роль согласующего, Workflow позволит ему согласовать собственный документ: в строке перехода (Workflow Transition) флаг «Allow Self Approval» по умолчанию включён. Действие: снять этот флаг на переходах согласования, а для сложных правил добавить условие перехода. Пятое: Workflow не даёт отменить документ. Причина — нет состояния с docstatus 2 и перехода в него; действие — добавить состояние и переход.

Подвожу границы подхода. Права ERPNext не заменяют регламент: если у вас нет владельца матрицы, она устареет за полгода. Маскирование v16 экспериментальное. Отчёты на сыром SQL требуют отдельной защиты. Логи доступа и аудит изменений настраиваются отдельно. Если вам нужно общее разграничение прав в инфраструктуре, смотрите материалы про права на сетевые папки NTFS и ограничение локального администратора: принцип минимальных прав общий.

Частые вопросы