NocoBase: старт за час, потом три недели на права доступа

MAATRIX

NocoBase выигрывает первое впечатление у любого no-code конкурента: разворачиваете контейнер, за час собираете модель данных под свой процесс, и кажется, что весь проект по автоматизации внутренних инструментов закрыт до обеда. Реальность наступает на второй неделе, когда выясняется, что у бухгалтера не должно быть доступа к зарплатным полям, у регионального менеджера — только к своим сделкам, а у стажёра — вообще ничего, кроме одной формы. Здесь быстрый старт заканчивается, и начинается настоящая работа с ACL, которая может растянуться на недели.

Что такое NocoBase и в чём его отличие от Airtable-клонов

NocoBase — open-source платформа, которая по описанию похожа на десяток других no-code инструментов: визуальный конструктор коллекций (таблиц), связи между ними, автоматически сгенерированный интерфейс для CRUD-операций, workflow-движок для несложной автоматизации. Разница в акценте. Baserow и NocoDB в первую очередь про интерфейс, похожий на Airtable, — таблица, вид Kanban, галерея, и вы работаете с данными примерно так же, как в облачном сервисе. NocoBase изначально строится вокруг модели данных и системы разграничения доступа как первоклассных сущностей, а не надстройки поверх готовой таблицы.

Технически это плагинная архитектура: ядро занимается моделью данных, ACL и workflow, а интерфейсные блоки (таблица, форма, канбан, календарь) подключаются как плагины. Обратная сторона — часть функциональности, которая в других инструментах есть «из коробки», здесь может требовать включения нужного плагина и настройки заново под конкретную коллекцию.

Backend — PostgreSQL, MySQL или SQLite на выбор при разворачивании; для чего-то серьёзнее прототипа стоит сразу ставить PostgreSQL, а не SQLite, — миграция между СУБД на живом проекте с уже настроенными правами доступа не тривиальна и может потребовать пересборки части конфигурации ACL заново, а не простого переноса данных. Если поднимаете PostgreSQL отдельным сервисом, а не встроенным SQLite, полезно заранее разобраться в базовой настройке — это разобрано в статье «Как установить и настроить PostgreSQL на VPS».

Первый час: от контейнера до рабочей модели данных

Быстрый старт — не маркетинговое преувеличение, это реально быстро. Минимальный docker-compose для теста выглядит примерно так (точные имена переменных окружения и версию образа сверяйте с актуальной документацией на момент установки — проект развивается активно и детали конфигурации со временем меняются):

version: "3"
services:
  app:
    image: nocobase/nocobase:latest
    restart: always
    ports:
      - "13000:80"
    environment:
      - APP_KEY=сгенерированный-длинный-случайный-ключ
      - DB_DIALECT=postgres
      - DB_HOST=postgres
      - DB_PORT=5432
      - DB_DATABASE=nocobase
      - DB_USER=nocobase
      - DB_PASSWORD=сгенерированный-пароль
    volumes:
      - ./storage:/app/nocobase/storage
    depends_on:
      - postgres
  postgres:
    image: postgres:15
    restart: always
    environment:
      - POSTGRES_USER=nocobase
      - POSTGRES_PASSWORD=сгенерированный-пароль
      - POSTGRES_DB=nocobase
    volumes:
      - ./postgres-data:/var/lib/postgresql/data

После docker compose up -d и первичной настройки администратора вы попадаете в визуальный конструктор коллекций. Создание таблицы «Сделки» со связями к «Клиентам» и «Менеджерам», настройка типов полей, вычисляемых значений и связанных представлений — всё это буквально перетаскивание блоков и заполнение форм, без единой строчки кода. За час собирается рабочий прототип: таблица сделок, карточка клиента, канбан по стадиям воронки. На этом этапе NocoBase действительно выигрывает у самописного решения на порядок по скорости.

Ловушка в том, что на этом этапе весь интерфейс открыт роли Admin, а сама демонстрация проекта коллегам обычно тоже идёт под учёткой администратора — и первое реальное столкновение с системой прав откладывается ровно до момента, когда нужно завести вторую роль с ограничениями.

Модель данных бесплатна, права доступа — нет

Здесь стоит зафиксировать честную формулировку: сложность в NocoBase не в том, что ACL плохо спроектирован. Он спроектирован достаточно гибко для реальных сценариев. Сложность в том, что эта гибкость требует ручной настройки под каждую роль, каждую коллекцию и каждое действие — и объём этой работы никак не сокращается тем, что модель данных уже готова.

Разница в подходе хорошо видна на контрасте. У Google Таблиц или Airtable права — это, по сути, «кто вообще видит документ» и изредка защита отдельных диапазонов. В NocoBase единица прав — тройка «роль + коллекция + действие», и по умолчанию новая роль не видит вообще ничего, пока вы явно не откроете ей доступ к каждой нужной коллекции и не укажете, какие именно действия разрешены. Это осознанный выбор в сторону безопасности по умолчанию (deny by default), а не удобства из коробки — и именно он превращает настройку прав из «поставить галочку» в проект с собственным планом работ.

Как на самом деле устроен ACL в NocoBase

Система прав строится на нескольких слоях, и путаница обычно возникает от того, что новичок пытается решить задачу на одном слое, хотя нужна комбинация всех:

Roles (роли) — именованные наборы прав, которые назначаются пользователям. Один пользователь может состоять в нескольких ролях одновременно, и по умолчанию действует объединение (union) разрешений всех его ролей — это важно держать в голове, потому что интуитивно ожидаешь более строгую (intersection) логику, а получаешь более мягкую.

Resources (ресурсы) — по сути, коллекции данных: «Сделки», «Клиенты», «Счета». Для каждого ресурса права настраиваются отдельно, и по умолчанию роль не имеет к ресурсу вообще никакого отношения, пока вы не откроете доступ явно.

Actions (действия) — стандартный набор: просмотр списка, просмотр записи, создание, редактирование, удаление, экспорт. Это уже привычная CRUD-матрица, знакомая по любой системе с ролевой моделью.

Field-level permissions (права на уровне поля) — вот здесь начинается специфика именно NocoBase: можно скрыть или сделать недоступным для редактирования не всю коллекцию, а конкретное поле внутри неё. Например, менеджер видит карточку сделки целиком, кроме поля с себестоимостью — это поле видно только роли «Финансы».

Data scope (область видимости данных) — самый мощный и самый неочевидный слой: правило вида «менеджер видит только те записи, где поле "ответственный" равно его собственному пользователю» или «региональный директор видит записи, где регион входит в список его регионов». Настраивается через условие-фильтр, похожее на конструктор фильтров в самой таблице, но применяется на уровне доступа, а не отображения.

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

Где всё ломается: нетривиальная оргструктура

Плоская структура — один отдел продаж, менеджеры и один руководитель — настраивается за пару часов: роль «Менеджер» с data scope по полю «ответственный», роль «Руководитель» без ограничения по scope, готово. Реальные компании редко устроены так просто, и вот на каких сценариях уходит основное время.

Многоуровневая иерархия. Руководитель отдела должен видеть сделки своих подчинённых, а не только свои. Data scope с условием «ответственный = я» этого не решает — нужна отдельная логика на уровне того, кто кому подчиняется, а сама иерархия подчинения — это ещё одна коллекция со связью «сотрудник → руководитель», к которой тоже нужно применить права, причём рекурсивно, если уровней подчинения больше двух.

Матричная структура. Сотрудник одновременно в проектной команде и в функциональном отделе, и видимость данных зависит от пересечения обоих контекстов — «эта сделка видна, если пользователь либо в команде проекта, либо руководитель функционального направления, к которому относится клиент». Такое условие в конструкторе фильтров data scope собирается, но само правило перестаёт быть тривиальным и требует отдельной коллекции-связки для хранения матричных отношений.

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

Разные права на разные поля одной записи в зависимости от роли, а не только видимость самой записи. Бухгалтер видит сумму сделки и статус оплаты, менеджер видит статус, но не видит внутреннюю комиссию, руководитель видит всё. Field-level permissions это умеют, но при десятках полей в коллекции и десятке ролей матрица настроек быстро превращается в таблицу, которую страшно менять, потому что легко забыть один угол.

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

NocoBase, Baserow, Appsmith: где чей фокус

Все три — open-source, все три можно развернуть на своём VPS, но решают разные по сути задачи, и выбор не в том, «что лучше», а в том, что ближе к вашему сценарию.

Если у вас плоская команда и задача — просто удобная таблица для совместной работы, Baserow быстрее в итоговой настройке: не заставляет продумывать пять слоёв ACL там, где хватило бы галочки «редактор / только просмотр». Сравнение Baserow с NocoDB, который решает похожую задачу немного иначе, разобрано в статье «NocoDB или Baserow: что выгоднее и когда». Appsmith — принципиально другой инструмент: он не хранит данные сам, а собирает интерфейс поверх уже существующих источников, и его ACL решает другую задачу — кто может публиковать и редактировать сами приложения, а не кто видит какие строки. Разворачивание Appsmith на своём VPS описано в статье «Как установить и настроить Appsmith на VPS».

Что делать, если у вас именно такая оргструктура

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

1. Формализуйте оргструктуру на бумаге, а не в интерфейсе. Таблица «роль → коллекции → действия → скрытые поля → data scope» до открытия NocoBase экономит больше времени, чем любая функция самого инструмента: настройка ACL в интерфейсе — это перенос уже принятых решений, а не место, где они принимаются впервые.

1. Начните с двух-трёх ролей, а не со всей матрицы сразу. Возьмите самую частую роль (рядовой менеджер) и самую строгую (внешний подрядчик), настройте и протестируйте их полностью на реальных тестовых пользователях, и только потом добавляйте промежуточные роли по образцу уже проверенных.

1. Заведите отдельную коллекцию для иерархии и связей, а не пытайтесь выразить подчинение только через data scope. Если руководитель должен видеть данные подчинённых, нужна таблица «сотрудник → руководитель», на которую ссылаются условия data scope других коллекций.

1. Тестируйте права под реальными учётками, а не под администратором. Самая частая причина «а почему у пользователя пусто» — проверка шла из-под роли Admin, у которой по умолчанию открыто всё, а не реальным входом под тестового пользователя с нужной ролью.

1. Документируйте матрицу прав отдельно от NocoBase. Через полгода никто не вспомнит логику каждого data scope, если она нигде не записана человеческим языком, а reverse-engineering условия фильтра в интерфейсе отнимает больше времени, чем чтение одной строки в документе.

1. Закладывайте на права отдельный срок в проекте, а не считайте это бонусом к сборке модели данных. Если модель данных занимает день, детальный ACL под сложную оргструктуру реалистично может занять от нескольких дней до нескольких недель.

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

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