Личный кабинет на 1С‑Битрикс
Создаём защищённый интерфейс для заказов, статусов, документов, обращений и персональных данных. Сначала описываем роли, жизненный цикл сущностей и источники информации, затем проектируем API, уведомления и контроль доступа — без обещаний универсального готового компонента.
Сценарии пользователя
Кабинет собирается вокруг задач, а не вокруг набора экранов.
Доступ и профиль
Регистрация, приглашение, подтверждение, восстановление доступа, изменение контактов и согласованные правила деактивации.
Заказы и статусы
История, состав, повтор заказа, статусы, оплаты и отгрузки показываются из определённого источника с понятной актуальностью.
Документы
Счета, акты, договоры и файлы доступны только связанному пользователю или организации; прямые URL также проходят проверку прав.
Обращения
Тема, приоритет, переписка, вложения и статус обращения связываются с клиентом и ответственным, а не остаются письмами без контекста.
Архитектура кабинета
Разделяем интерфейс, доменную логику, хранение и внешние системы.
Модель ролей
Пользователь, организация, договор и полномочия хранятся как отдельные сущности. Интерфейс не должен быть единственной защитой.
API‑слой
Контракты описывают поля, статусы, ошибки, версионирование и идемпотентность. Секреты и служебные данные не попадают в браузер.
Уведомления
Канал, событие, шаблон и возможность отказа проектируются отдельно. Повтор отправки не должен дублировать бизнес‑операцию.
Журнал
Вход, смена важных данных, загрузка документа и изменение статуса фиксируются в согласованных границах.
Риски до разработки
Большинство дорогих переделок возникает из-за неописанных прав и источников данных.
Дубли пользователей
Email или телефон не всегда являются устойчивым ключом организации. Нужны правила объединения и подтверждения принадлежности.
Смешение контрагентов
Один пользователь может представлять несколько компаний; права нельзя определять только по профилю.
Устаревшие статусы
При пакетном обмене показываем время обновления и корректно обрабатываем задержку, а не создаём ложное ощущение реального времени.
Ссылки на файлы
Закрытый документ нельзя защищать только скрытой кнопкой: выдача файла обязана проверять сессию и право.
Приёмка
Набор тестов строится по матрице роль × сущность × действие.
Авторизация
Успешный и неуспешный вход, восстановление, истечение сессии и блокировка проверяются отдельно.
Права
Каждая роль проходит позитивные и негативные сценарии чтения, изменения и скачивания.
Интеграция
Проверяем начальную загрузку, изменение, повтор события, недоступность внешней системы и восстановление.
Адаптивность
Критичные действия доступны с клавиатуры и на мобильном экране без потери данных или функций.
Когда это правильный выбор
До оценки сверяем не только желаемый результат, но и более простой или безопасный способ решить задачу.
Подходит
Пользователю нужен защищённый доступ к персональным заказам, документам, обращениям, статусам или настройкам.
Достаточно публичной формы
Если данные не персональны, история не нужна, а обращение может обрабатываться без авторизации и постоянного профиля.
Нужен B2B‑портал
Если добавляются организации, договоры, лимиты, индивидуальные цены, склады и многоступенчатое согласование закупки.
Сначала модель доступа
Если неизвестно, кто и на каком основании видит документ, разработку интерфейса нельзя начинать безопасно.
Из чего складывается оценка
Точная цена появляется после проверки входных данных. До этого показываем факторы и выбранную модель расчёта, а не ложную фиксированную цифру.
Роли и действия
Считаются не экраны, а разрешённые операции каждой роли над заказом, документом, обращением и профилем.
Источники данных
Локальное хранение, API, очередь и обратные статусы имеют разную сложность и требования к отказоустойчивости.
Безопасность
Двухфакторный вход, аудит, защищённые файлы и специальные требования увеличивают глубину реализации и проверки.
Миграция
Старые пользователи, пароли, документы и история требуют карты соответствия и контрольных выборок.
Проектный маршрут
Каждый этап имеет вход, передаваемый результат, ответственного и критерий перехода к следующему.
Контекст
Собираем цель, аудиторию, текущее состояние, доступы, зависимости и известные ограничения конкретной услуги.
Требования
Переводим пожелания в роли, сценарии, данные, интерфейсы и критерии, по которым можно принять результат.
Архитектура
Определяем границы модулей, источник данных, интеграции, кеширование, безопасность и точки отказа.
Оценка
Смета связывает этап с результатом, показывает внешние расходы, исключения и условие пересмотра.
Реализация
Изменения выполняются в пользовательском коде и по возможности на тестовой среде, проходят review и миграции.
Тестирование
Позитивные, негативные, ролевые, адаптивные и регрессионные сценарии соответствуют риску изменения.
Запуск
Резервная копия, контрольный список, окно публикации, smoke‑test и rollback согласуются до изменения продакшена.
Передача
Заказчик получает код, настройки, доступы, инструкции, список изменений, ограничения и понятный следующий backlog.
Частые вопросы
Ответы помогают заранее определить границы задачи и данные, которые потребуются для оценки.
Личный кабинет можно добавить в существующий сайт?
Да, если текущая редакция, архитектура пользователей, шаблон и интеграции позволяют безопасно встроить новый контур. До оценки проверяем модификации ядра, авторизацию и модель данных.
Сколько экранов потребуется?
Количество экранов следует из ролей и сценариев. Один и тот же статус может требовать разных действий для клиента и менеджера, поэтому считать только макеты недостаточно.
Можно использовать стандартные компоненты?
Часть задач закрывается системными механизмами, но бизнес‑процессы, документы и интеграции обычно требуют собственной модели. Совместимость проверяется по фактической редакции и версии.
Как оценивается проект?
По ролям, сущностям, действиям, интеграциям, требованиям к безопасности, миграции и нагрузке. До полной сметы можно выделить отдельный этап обследования и прототипирования.
Нужна ли двухфакторная авторизация?
Это определяется моделью угроз и ценностью данных. Наличие технической возможности не заменяет проектирование восстановления доступа, резервных кодов и поддержки пользователей.
Связанные направления
Перейдите к соседней задаче или посмотрите общий состав проекта и действующие ориентиры стоимости.
Начнём с границ задачи
Укажите адрес сайта или тип нового проекта, ожидаемый результат и известные ограничения. Ответим с уточняющими вопросами и предложим разумный следующий шаг.