Концепт «Филиал»

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

Концепт-проект: «Филиал» — вымышленная компания. Результатов работы здесь нет: только решения и гипотезы.

О заказчике

• Сценарий: Облачный продукт для независимых сетей сервисных центров
• Пользователи: Владелец сети, управляющий филиала, сотрудник и оператор продукта
• Первая версия: Рабочие пространства, филиалы, задачи, приглашения и подписка
• Граница: Касса, бухгалтерия и универсальный конструктор процессов остаются за пределами MVP
• Данные: Сети, адреса, роли и показатели интерфейса вымышлены

Задача

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

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

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

Риски исходного процесса

Данные разных сетей смешиваются

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

Новая точка требует ручной настройки

Организация проходит короткую последовательность: филиалы, рабочие роли и приглашения. Незавершённые действия сохраняются, а подсказка показывает следующий обязательный шаг.

Сотрудник сохраняет прежний доступ

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

Оплата превращается в потерю данных

Окончание подписки имеет явную политику. Текущие данные не удаляются автоматически в момент неудачного списания; права на экспорт и сроки хранения определяются до запуска.

Решение

Разделяем организацию-клиента SaaS и филиал внутри неё. Переключатель рабочего пространства меняет контекст пользователя; сервер каждый раз проверяет участие в организации и допустимый набор филиалов. Руководитель сети получает сводку только своей сети, сотрудник точки работает с локальными задачами и назначениями.

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

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

Как устроен продукт

1. Переключатель пространства. Название текущей организации, доступные филиалы и явный переход между разрешёнными контекстами. Зачем: Пользователь всегда понимает, где создаёт данные.
2. Обзор сети. Филиалы, локальные исключения и незавершённые задачи; представление списком дополняет карту. Зачем: Адрес не является единственным способом найти нужную точку.
3. Рабочее место филиала. Очередь задач, владелец, срок и история действий с фильтрами для роли сотрудника. Зачем: Сводка сети не перегружает ежедневную работу исполнителя.
4. Приглашения и роли. Выбор организации и филиалов, срок ссылки, подтверждение принятия и отзыв. Зачем: Ошибка приглашения не превращается в неограниченный доступ.
5. Подписка и возможности. Текущий период, доступные функции, причина ограничения и понятное действие администратора. Зачем: Пользователь отличает лимит продукта от недостатка полномочий.
6. Журнал и экспорт. Административные события и контролируемая выгрузка разрешённого набора данных. Зачем: Выход из продукта не требует скрытых действий поддержки и не раскрывает соседние сети.

Что помогает пройти сценарий

Подключение с продолжением

Шаги настройки хранятся на сервере. Администратор возвращается к незавершённому приглашению или филиалу; повтор создания с тем же идентификатором не размножает рабочие пространства.

Доступ в контексте роли

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

Предсказуемое ограничение подписки

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

Ключевые сценарии

Подключить филиал

Администратор добавляет точку и приглашает сотрудника только в разрешённый контекст.

На входе: Сеть уже создана; сотрудник должен работать в филиале «Центр», но не в остальных точках.

1. Создать филиал и задать обязательные параметры.
2. Выбрать роль сотрудника и единственный допустимый филиал.
3. Отправить приглашение с ограниченным сроком.
4. После принятия показать контекст и доступную очередь задач.

На выходе: Сотрудник включён в нужную организацию и видит назначенный филиал; незавершённая настройка остаётся видимой администратору.

Если что-то пошло не так: Отозванная или просроченная ссылка не создаёт участника. Повтор принятия действующего приглашения возвращает прежнее участие.

Критерий приёмки: Прямой запрос сотрудника к чужому филиалу не раскрывает задачи или вложения. Повтор приглашения не создаёт второй аккаунт участия.

Сменить доступ

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

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

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

На выходе: Новое действие выполняется только в допустимом контексте; старая вкладка показывает понятное ограничение.

Если что-то пошло не так: Ссылка на ранее разрешённый файл не предоставляет постоянное исключение. Права проверяются при выдаче документа, а кеш содержит контекст организации.

Критерий приёмки: С действующим токеном нельзя продолжать чтение исключённого филиала. История не переименовывает прежнего автора.

Обработать подписку

Повторный или запоздалый ответ платежного провайдера не должен создавать лишний период или терять рабочие данные.

На входе: Администратор оплатил период; уведомление приходит повторно, затем доставляется более старое состояние.

1. Проверить подлинность и идентификатор уведомления.
2. Сохранить событие до применения бизнес-действия.
3. Обновить подписку по согласованным правилам состояний.
4. Показать доступные функции и действующий период организации.

На выходе: Оплата обработана один раз; сотрудник получает возможности своей роли, а текущие данные остаются в принятой политике хранения.

Если что-то пошло не так: Ошибку подписи нельзя принять как оплату. При окончании периода сервер применяет заранее описанные ограничения и сохраняет разрешённый экспорт.

Критерий приёмки: Повтор не продлевает период второй раз. Старое событие не отменяет новый подтверждённый статус без предусмотренного перехода.

Роли пользователей

Владелец сети

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

Как точка работает и кто имеет доступ к её данным?

Управляющий филиала

Назначает локальные задачи и отвечает за их выполнение.

Что просрочено в моём филиале и кому назначено?

Сотрудник и оператор продукта

Сотрудник выполняет задания; оператор разбирает технические обращения по отдельным полномочиям.

Как получить нужный контекст без доступа к чужим организациям?

Как устроено технически

Разделение организаций

Вариант модели: идентификатор организации в каждой принадлежащей ей записи, централизованная проверка принадлежности и роли на сервере. Составные связи, вложения, фоновые задания и кеши проверяем на смешение контекста.

Права и активные сессии

Роли назначаются на уровне сети и филиала. При смене полномочий сервер повторно проверяет доступ; приглашения имеют срок и отзыв. Управление секретами и техническая поддержка не оформляются как обычная роль сотрудника.

Подписка и повтор событий

Платёжный провайдер выбирается отдельно; сервер проверяет подлинность уведомления, сохраняет событие и обрабатывает его повтор безопасно. Очерёдность уведомлений и возврат не должны неожиданно открыть оплаченные функции.

Наблюдаемость и обслуживание

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

Что входит в разработку

• Выбор сегмента и модели самостоятельного подключения
• Прототип пространства, филиала и рабочего задания
• Организации, участники, роли и приглашения
• Централизованные проверки доступа и журнал
• Список и карта филиалов с локальными очередями
• Согласованная политика возможностей подписки
• Интеграция выбранного провайдера с проверкой повторов
• Экспорт разрешённых данных и план восстановления
• Приёмочные проверки подмены контекста
• Пилотная организация и обучение администратора

План реализации

1. Продуктовая модель: выбираем один сегмент сервисных сетей, определяем организацию, филиал, роли и границы первой версии.
2. Прототип подключения: проверяем создание пространства, приглашение сотрудника и исполнение задачи филиала.
3. Серверный контур: реализуем разделение организаций, проверку прав, журнал и идентификаторы повторных событий.
4. Проверка подписки: проигрываем окончание периода, повтор оплаты, возврат и доступ к данным по принятой политике.
5. Ограниченный запуск: подключаем пилотную организацию после технической приёмки и наблюдаем причины незавершённых сценариев.

Что замеряем после запуска

• Завершение подключения — Отслеживаем создание организации, первого филиала и принятие первого приглашения. Техническое создание записи не считается началом реальной работы сотрудников.
• Доступ к чужому контексту — Приёмочные проверки подменяют организацию, филиал и идентификатор файла в прямом запросе. Отсутствие кнопки не является положительным результатом этой проверки.
• Выполнение задачи филиала — Измеряем создание, назначение, начало и завершение для одинаковых типов задач. Просрочку сопоставляем с изменениями сроков и причиной переназначения.
• Корректность подписки — Проверяем повтор уведомления, запоздалый статус и окончание периода. Функции меняются по серверному состоянию; при этом не возникает второго периода из одного события.

Стек

React, TypeScript, PostgreSQL, Серверные роли и очереди.

Все кейсы · Услуга · Калькулятор стоимости

Визуализация продукта

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