#recoil #react #js #reactjs #crm #surecrm #разработка приложений #программирование #opensource #open source
SUREcrm - это свободная (opensource) CRM система. На самом деле, это скорее система общего назначения для управления бизнесом (ERP). Это платформа, снабженная всем необходимым для создания enterprise-wide облачных приложений. Предусмотрена JWT-авторизация. Каждый арендатор (tenant) имеет возможность регистрировать своих пользователей и регулировать их доступ. У каждого арендатора есть возможность создавать нужные ему роли и назначать эти роли своим пользователям. Арендатор создает необходимое количество разделов(областей видимости) для информации своего предприятия и назначает, какая роль будет иметь доступ к тем или иным разделам. Интегратор системы может свободно дорабатывать сущности и связи в системе, формы, справочники. Для того, чтобы свободно ориентироваться в этом - создается данное описание. Система в настоящее время находится в процессе разработки. О текущем состоянии можно узнать по последним коммитам в https://github.com/levtrilev/surecrm. В качестве облачного решения система пока не запущена. Но есть онлайн доступ для ознакомления https://surecrm.vercel.app/
Контрибьюторы приветствуются!
Используемый стек технологий
В качестве сервера используется виртуальная машина Ubuntu 20.04.
В качестве СУБД используется PostgreSQL.
В качестве сервера приложений используется PostgREST.
Инструкция по установке PostgreSQL + PostgREST см. https://postgrest.org/en/stable/tutorials/tut0.html
Автодокументация ("swagger":"2.0") API системы см. https://surecrm.org/
В качестве web-сервера используется Nginx. См предложенный Nginx configuration file здесь https://postgrest.org/en/stable/admin.html?highlight=nginx#hardening-postgrest
В качестве frontend используется React 17 (typescript), Recoil, Material-UI 5
Репозиторий git (frontend): https://github.com/levtrilev/surecrm
Для администрирования СУБД установлен pgAdmin4 for web. См.инструкцию по установке здесь https://ruvds.com/ru/helpcenter/postgresql-pgadmin-ubuntu/
Описание структуры БД
Название таблиц бизнес-сущностей используется во множественном числе. Например «products», «customers». В названиях объектов БД используются только маленькие латинские буквы. Для составных названий используется кебаб-нотация, т.е. в качестве разделителя используется знак «_», например «order_products».
Для каждой бизнес-сущности в БД создается таблица с обязательными полями «id» (Primary Key) и «name» (not null, unique). «name» используется в представлениях, как строка поиска и выбора уникального объекта по названию.
Если сущность ссылается на другую сущность, то поле называется «сущность_id» (сущность в единственном числе) и это поле объявляется Foreign Key. Например, «product_id», «order_id».
В каждой таблице обязательно имеются поля «tenant_id» и «section_id». «tenant_id» - это идентификатор владельца эккаунта пользователя SaaS-сервиса. «section_id» - это идентификатор раздела для разделения доступа внутри одного эккаунта (внутри одного предприятия) для разных ролей пользователей.
Поскольку у разных SaaS-эккаунтов не должно быть доступа к записям других эккаунтов, для разделения доступа используется создание над таблицей бизнес-сущности ограничивающего доступ view. У пользователей (пользователь БД) определенного эккаунта сконфигурирован доступ на чтение и запись к view, но не к таблице. В определении view используется условие WHERE user = current_user. Более полно (пример для «products»):
…WHERE (products.section_id IN ( SELECT role_section.section_id
FROM api.role_section
WHERE (role_section.role_id IN ( SELECT role_user.role_id
FROM api.role_user
WHERE (role_user.user_id IN ( SELECT users.id
FROM api.users
WHERE (users.name::text IN ( SELECT CURRENT_USER AS "current_user"))))))));
В условии упоминаются таблицы:
«users» - пользователи;
«role_user» – какие роли выполняет пользователь;
«role_section» – к каким разделам имеет доступ роль.
Автонумерация для id. Для каждой таблицы определен объект Sequence, автоматически присваивающий следующий id при вставке записи в таблицу. Напимер, products_id_seq для products. При добавлении пользователей к этому объекту также необходимо предоставлять доступ (о конфигурировании доступа для новых пользователей будет отдельное описание).
После внесения любых изменений в структуру объектов БД необходимо в командной строке терминала сервера дать команду обновления схемы API – в моем случае это: «postgrest rest_api.conf» и получить подтверждение «Schema cache loaded».
Для доступа к API используются соответствующие запросы GET, POST, DELETE – см. соответствующий раздел документации PostgREST: https://postgrest.org/en/stable/api.html
В нашем случае мы направляем эти запросы не к таблицам, а к view. Попробуйте в браузере (там есть немного данных для анонимного пользователя) : https://surecrm.org/view_orders
Соответственно, если в «Headers» запроса добавляется параметр «Authorization», содержащий соответствующий токен пользователя, то будет осуществлен доступ к записям только тех разделов, которые сконфигурированы этому пользователю.