Чтобы прораб видел только свой объект: User Permissions в ERPNext

Чтобы прораб видел в ERPNext только свой объект, ему назначают роль с доступом к заявкам и создают User Permission на его Project и склад. Роль даёт доступ к типу документов, а User Permission сужает записи. Ниже порядок настройки, Strict-режим и проверка.

Как ограничить прораба одним объектом: роль плюс User Permission

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

Порядок настройки такой. Сначала создаётся роль «Прораб» и в менеджере прав ролей (Role Permissions Manager) ей выдаются права на нужные документы: например Read, Write и Create на Material Request, Read на Project и Item, без Delete и без Submit там, где проводка не нужна. Затем создаётся пользователь с этой ролью. Затем в DocType User Permission заводятся записи: пользователь, тип в поле Allow (Project) и значение в For Value («Объект А»). Вторая запись ограничивает склад: Allow = Warehouse, For Value = «Склад объекта А». Если включить флажок Is Default, значение будет подставляться в формы автоматически, и прорабу не придётся выбирать объект при каждой заявке.

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

Базовая роль обязательна. User Permission работает только как сужение: если у пользователя нет роли с правом на документ, ничего не появится, сколько записей ни создавай. А если роль есть, а User Permission не заведён, пользователь видит все записи этого типа. В нашей базе знаний этот вывод назван главной граблей, и я с ним согласен: именно её я вижу чаще всего на первых проверках.

• Создать роль «Прораб» и выдать права на заявки, проекты, номенклатуру в Role Permissions Manager.
• Создать пользователя и назначить ему роль.
• Завести User Permission на Project с объектом прораба.
• Завести User Permission на Warehouse со складом объекта.
• Войти под прорабом и проверить списки, отчёты, поиск и поля выбора.

Как ограничение переходит на заявки, заказы и задачи

Чтобы понять, что именно увидит прораб, полезно знать механику. В исходниках Frappe версии 15 проверка прав доступа к записи выполняется в два шага. Сначала система смотрит, есть ли для пользователя правила на сам тип документа: если открывается проект, а правила заведены на Project, то разрешены только перечисленные проекты. Затем система проверяет все Link-поля документа, включая строки дочерних таблиц: если поле ссылается на Project, а для пользователя заведены правила на Project, значение должно входить в разрешённый список. Из этого и следует то, что заявка, заказ или задача «чужого» проекта не откроются: система вернёт сообщение о том, что доступ к записи запрещён, потому что она связана с недоступным значением.

Теперь о том, где у документов стоит поле проекта. По описанию полей в версии 15 у Purchase Order, Purchase Receipt, Stock Entry и Task поле Project есть в заголовке документа. А у Material Request поля проекта в заголовке нет: Project стоит только в строках позиций. Склад в заголовке есть (поле Set Target Warehouse, это Link на Warehouse), и в строках тоже. Это важно, потому что списки строятся иначе, чем проверка отдельной записи. Условия для списка в коде строятся по Link-полям самого типа документа, а не по полям дочерних таблиц. Значит, для заявок на материалы фильтрация списка по проекту через строки может работать иначе, чем для заказов, а ограничение по складу, наоборот, может срезать список через заголовочное поле Set Target Warehouse, и поведение нужно проверить на своём стенде и в своей версии, а не полагаться на общий вывод.

Я проверяю так: создаю две заявки на разные проекты, захожу под прорабом и делаю три вещи. Открываю список заявок и смотрю, что в нём есть. Пытаюсь открыть чужую заявку по прямой ссылке. Ищу номер чужой заявки в глобальном поиске. Если список показывает больше, чем нужно, а открыть чужую заявку нельзя, это известное поведение, и прорабу достаточно доступа без списка чужих номеров. Если открыть можно, значит, правила настроены неверно, и причину нужно искать в Link-полях и в записях User Permission.

| Документ | Поле Project | Поведение, которое нужно проверить на стенде | |---|---|---| | Purchase Order | в заголовке | Список и запись фильтруются по Project | | Purchase Receipt | в заголовке | Список и запись фильтруются по Project | | Stock Entry | в заголовке | Список и запись фильтруются по Project | | Task | в заголовке | Список и запись фильтруются по Project | | Material Request | только в строках позиций | Запись проверяется по строкам, список проверьте отдельно | Таблица составлена по описанию полей версии 15. Ваша версия и ваши настройки (например, собственные поля) могут отличаться, поэтому перед запуском пройдите все пять строк под тестовым прорабом.

Applicable For: когда фильтровать только часть типов документов

По умолчанию запись User Permission действует на все типы документов, где есть ссылка на указанный объект. В форме записи для этого стоит флажок Apply To All Document Types. Если его снять, открывается поле Applicable For, где выбирается конкретный DocType, и фильтр применяется только к нему. Зачем это нужно? Например, вы хотите ограничить прораба одним проектом в документах закупки, но разрешить ему видеть все объекты в справочнике задач: тогда для Project правило привязывается только к заявке или заказу.

На практике я использую Applicable For редко. Чем проще правило, тем меньше сюрпризов, и «ограничить везде» легче объяснить директору, чем «ограничить здесь, но не там». Но бывают случаи, когда оно нужно: например, бухгалтер должен видеть все платежи, но в справочнике проектов видеть только перечень активных, либо руководитель участка отвечает за два объекта и в документах закупки видит оба, а в документах склада только один.

Одно ограничение нужно знать наперёд. В коде версии 15 дубликаты записей User Permission отсекаются: нельзя завести две одинаковые записи с тем же пользователем, объектом, значением и областью применения. Если вы пытаетесь «поправить» правило, не удаляя старое, получите ошибку «User permission already exists». Удалите или измените существующую запись.

Склад и компания: ограничиваем не только проект

User Permission работает с любыми Link-полями, поэтому ограничить можно не только проект, но и склад, и организацию. Для прораба я всегда ограничиваю склад объекта: иначе он увидит остатки, перемещения и приходы чужих площадок, а это уже коммерческая информация. Здесь пригодится дерево складов, которое мы описывали в материале про приёмку материалов на объект: склады образуют иерархию, а запись на родительский склад распространяется на дочерние.

Это правило видно в коде: для вложенных типов (Warehouse относится к таким) при получении прав система добавляет в разрешённые значения всех потомков указанного узла. Поэтому, если прорабу разрешена группа «Объект 001», он получает и её дочерние склады, например «Площадка монтажа». Чтобы отключить такое наследование, в записи есть флажок Hide Descendants. Для прораба с одним объектом наследование обычно полезно, а для начальника, который не должен видеть подчинённые участки, его включают.

Отдельно про организацию. User Permission на Company оставляет пользователю только записи его организации, и это важно для групп компаний с общей базой. Для компании на 14 рабочих мест с одной организацией этот слой не нужен, но если у вас две организации (например, подрядное и торговое юрлицо), заведите правило сразу и проверьте, что не попали в отчёты по чужому юрлицу. Общую модель прав на уровне ролей и полей разбирают в материале про матрицу доступа в 1С: принципы похожи, хотя система другая.

Strict-режим и проверка: где прораб всё ещё может увидеть лишнее

В System Settings есть флажок Apply Strict User Permissions. Его описание в коде звучит так: если включён строгий режим и для пользователя заведены правила на тип, то документы, где значение ссылки пустое, показаны не будут. Без строгого режима документ с пустым проектом виден всем: система считает пустое значение «ничьим» и пропускает его. Это удобно на старте, но опасно: заявка без проекта видна любому прорабу. Строгий режим закрывает эту дыру, но создаёт обратную: все старые документы без проекта исчезают из списков у ограниченных пользователей.

Поэтому порядок включения такой. Сначала на тестовом сайте найдите документы без проекта (отчётом или фильтром «Project is not set»). Затем заполните проект там, где это можно, а там, где нельзя, примите, что такие документы будут видны только неограниченным ролям. И только после этого включайте строгий режим на рабочем сайте. Включать его первым делом на живой системе я не советую: прораб не увидит свои старые заявки и решит, что данные потеряны.

Проверка — отдельный этап, и его нельзя пропускать. После настройки войдите под прорабом и пройдите по списку: списки документов, отчёты, Kanban-доска, глобальный поиск, поля выбора проекта и склада при создании новой заявки, печатные формы. Особое внимание отчётам: стандартные отчёты применяют правила так, как заложено в их коде, а свои отчёты на произвольных запросах могут правила не учитывать. Эта ситуация в нашей базе знаний тоже помечена как пункт проверки на стенде: достоверно обхода я не утверждаю, но и исключить его без проверки нельзя.

Что делать, если что-то видно лишнее. Если виден весь список проектов, значит, не создана запись для Project. Если не виден свой проект, нет базовой роли или правило привязано к другому типу через Applicable For. Если чужое видно через отчёт, ограничьте сам отчёт или уберите его у роли. Если старые документы пропали, проверьте строгий режим. Ещё один частый случай: вы создали запись, но пользователь жалуется, что ничего не изменилось. Кэш прав пользователя в коде сбрасывается при сохранении записи User Permission, но иногда помогает выход из системы и повторный вход.

Как «Три Прораба» на 14 рабочих мест разделила объекты между бригадами

Условный пример: строительная компания «Три Прораба», 14 рабочих мест, три бригады на трёх объектах, плюс снабженец, бухгалтер и директор. До настройки прорабы заходили под одной ролью и видели все объекты: чужие заявки, чужие склады, остатки конкурирующей бригады. Это порождало споры о том, кому достался материал. Числа в примере условные и нужны для иллюстрации хода работ, а не как результат реального клиента.

Настройку сделали за два дня на тестовом сайте. Завели роль «Прораб» и три учётные записи, для каждой — по две записи User Permission: на Project своего объекта и на Warehouse своего склада, с отметкой Is Default. Проверка под каждым прорабом показала три замечания. Старые заявки без проекта (условно семь штук) пропали у прорабов после включения строгого режима, и проект в них пришлось дозаполнить. У директора по ошибке оказалась запись на один проект, и он видел только один объект, запись удалили. А прораб второй бригады не мог создать заявку, пока ему не отметили склад по умолчанию.

После исправлений каждый прораб видит в своих списках только свой объект, в поле проекта ему предлагается лишь одно значение, склад подставляется сам. Снабженец, бухгалтер и директор записей User Permission не получили и видят все три объекта. Результат условный: для вашей компании поведение придётся проверить на вашем стенде, на что хватает дня. На демостенде erp-demo.itfresh.ru по запросу покажем, как выглядит такой доступ глазами прораба. Контроль доступа подрядчиков к сети — отдельная тема, о ней есть материал про доступ подрядчиков в сеть.

Как не ограничить лишнего: руководители и бухгалтерия

Обратная ошибка так же частая: ограничили слишком многих. Руководитель, снабженец и бухгалтер должны видеть все объекты, и для них записи User Permission не создаются. Это следует из логики: правило сужает, а без правил на этот тип сужения нет. В нашей базе знаний есть совет «снять флаг Apply User Permissions для руководящих ролей». В исходниках версии 15 в описании прав роли (DocPerm) такого флажка я не нашёл, поэтому для сквозного доступа достаточно не заводить записи. Если вы работаете на другой версии и видите такой флажок, проверьте его назначение на стенде.

Пользователь Administrator правилам вообще не подчиняется: в коде для него возвращается пустой набор правил. Поэтому проверять ограничения нужно не под администратором, а под тестовой учётной записью с ролью прораба, иначе вы ничего не увидите. Учётные записи с широкими ролями вроде System Manager заводить прорабам нельзя: это отдельная история с правами на настройку системы, а не на документы.

Теперь об ограничениях метода. User Permission хорошо ограничивает записи, но не заменяет аудит: он не показывает, кто и когда смотрел документ, и не защищает от ошибки администратора. Он не закрывает права на поля (для этого есть уровни прав полей) и не касается выгрузки на уровне файлов вне системы. Аудит доступа на уровне файловых ресурсов лучше строить отдельно, как в материале про аудит прав доступа к папкам и файлам. Наконец, чем больше правил, тем сложнее сопровождать: при приходе нового прораба нужно не забыть добавить две записи, а при увольнении убрать пользователя и записи. Я веду для этого короткий регламент в карточке проекта.

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