Если изменение конфигурации или бизнес-данных может затронуть других пользователей, приложению может потребоваться процесс, в котором один человек предлагает изменение, а другой проверяет его до применения. Спроектировать такой процесс согласования изменений в SaaS на PHP — значит не просто добавить кнопку «Согласовать»: нужно отделить предложение от актуальных данных, защитить каждый переход между состояниями и определить, что делать, если контекст изменится, пока запрос ожидает решения.
Система должна позволять проверить, что именно запросили, кто это проверил, какими правами он обладал и было ли изменение в итоге применено. Решение должно соответствовать уровню риска: лишний процесс согласования создаёт неудобства, а недостаточный может привести к некорректным или трудноотслеживаемым изменениям.
Определите, какие изменения требуют согласования
Для начала классифицируйте изменения по их влиянию, охвату и возможности исправления. Не каждое редактируемое значение требует проверки. Пользователь может напрямую сохранить изменение личной настройки с низким уровнем риска. В то же время для изменения правила выставления счетов, конфигурации, общей для организации, или основных данных, влияющих на несколько процессов, может быть разумно требовать согласования.
Задайте явные критерии на уровне продукта. Например, выясните, затрагивает ли изменение других пользователей, помимо его инициатора, может ли оно повлиять на суммы или права доступа, требует ли внутренняя политика участия второго человека и насколько дорого обойдётся исправление. Также задокументируйте исключения и укажите, кто вправе их менять. Не превращайте согласование в универсальный механизм для операций, не относящихся к этому случаю: речь идёт об изменениях конфигурации или бизнес-данных.
Это решение должно применяться на сервере, а не только в интерфейсе. Скрытая кнопка не помешает вызвать endpoint напрямую. API должен определять, требует ли данный тип изменения согласования, и применять это правило как к отдельным операциям, так и к массовым действиям и интеграциям, способным изменить то же значение.
Отделите запрос от актуальных данных
При создании предложения не перезаписывайте актуальные данные. Храните запрос отдельно, указав как минимум организацию, затронутый ресурс, предлагаемые значения, состояние, автора и время создания. В зависимости от продукта также может потребоваться сохранять причину, источник запроса, срок действия или версию исходных данных.
Для представления значений можно хранить типизированные поля или структуру, сериализованную и проверенную сервером. В обоих случаях не принимайте произвольную полезную нагрузку так, словно это обычное обновление данных. При получении предложения проверяйте схему, допустимые поля, форматы и бизнес-правила. Повторно проверьте всё необходимое при применении: пока запрос ожидал решения, условия могли измениться.
Такой подход позволяет сравнить актуальное и предложенное значения, не меняя опыт других пользователей. Кроме того, экран проверки может наглядно показать различия. Не представляйте ожидающее решения значение как актуальное: чётко указывайте, какие данные уже применены, а какие пока являются предложением.
Явно смоделируйте состояния и переходы
Определите небольшой набор состояний с точными значениями. Обычная последовательность может включать proposed (предложено), in_review (на проверке), approved (согласовано), rejected (отклонено), expired (срок действия истёк) и applied (применено). Не каждому продукту требуется состояние проверки: если достаточно принять решение сразу, его можно не использовать. Важно, чтобы каждое состояние описывало рабочую ситуацию, а не было просто декоративной меткой.
Задайте допустимые переходы. Например, предложение можно отправить на проверку или отклонить; запрос на проверке можно согласовать или отклонить; согласованное изменение можно применить, если оно всё ещё актуально. Запрос с истёкшим сроком действия не следует согласовывать тем же путём, что и активный запрос. Недопустимые действия должны завершаться единообразным ответом, даже если интерфейс не предлагает такой вариант.
Состояния «согласовано» и «применено» — не одно и то же. Согласование фиксирует решение, а применение изменяет актуальные данные. Разделение этих этапов позволяет выявлять сбои при применении и показывать согласованные запросы, которые ещё требуют внимания. Если процесс можно завершить в рамках одной короткой транзакции, решение и запись можно выполнить согласованно, но модель всё равно должна различать произошедшие события.
Проверяйте права доступа при каждом переходе
Авторизуйте каждое действие на сервере с учётом организации, роли, ресурса и его текущего состояния. Не считайте, что право создать запрос автоматически даёт право согласовать или применить его. Не доверяйте и идентификатору организации, полученному от клиента: определяйте область доступа по проверенной сессии или учётным данным и убеждайтесь, что запрос и ресурс относятся к одной и той же области.
Если самосогласование запрещено, проверяйте, что согласующий и автор предложения — разные лица. Это правило нужно выполнять при переходе состояния, а не только в представлении. Кроме того, определите порядок работы с запросами администраторов, сервисных пользователей и автоматизированных процессов: исключения должны быть результатом осознанной политики, а не случайным упущением.
Согласование должно быть связано с конкретным предложением. Если его содержимое меняется, прежнее согласование теряет силу: создайте новую версию запроса или верните его в состояние, требующее повторной проверки. Незаметное изменение значений после согласования нарушает соответствие между проверенным и применённым содержимым.
Управляйте конкурентным доступом, сроком действия и применением
Пока запрос ожидает решения, другой участник может изменить исходные данные. Чтобы обнаружить это, сохраняйте при создании предложения версию ресурса или значимые исходные значения. При применении сравнивайте ожидаемую версию с актуальной. Если они не совпадают, не перезаписывайте новое изменение без проверки: заблокируйте применение, отметьте конфликт или запросите повторную проверку в соответствии с правилами продукта.
В реляционной базе данных транзакция может защитить чтение запроса, проверку его состояния и обновление ресурса. Конкретный подход зависит от СУБД и уровня параллелизма; могут подойти пессимистическая блокировка или условное обновление по версии. В любом случае переход должен быть атомарным: две одновременные заявки не должны приводить к повторному применению одного и того же изменения.
Сделайте применение идемпотентным или обеспечьте безопасный отказ при повторных попытках. Если помимо обновления данных в базе отправляется уведомление или публикуется событие, рассмотрите возможность записывать ожидающее событие в той же транзакции и обрабатывать его позже. Это снижает риск отправки уведомления об успехе, когда запись не была подтверждена.
Также задайте политику срока действия: как долго предложение может оставаться активным, что приводит к его истечению и можно ли продлить срок. Проверять истечение срока нужно на сервере при согласовании и применении; недостаточно просто менять состояние с помощью фоновой задачи. Если из-за задержки значения или условия перестают быть надёжными, требуйте создать новое предложение.
Аудируйте процесс и обеспечьте его работу
Храните сведения о том, кто предложил, согласовал, отклонил и применил каждое изменение, а также даты, идентификаторы организации и ресурса, результат и контекст, необходимый для расследования. Сохраняйте ссылку на версию предложения и принятое решение. Запись аудита нельзя изменять с помощью обычных функций редактирования запросов. Ограничивайте собираемые данные необходимым минимумом и соблюдайте политики доступа и хранения, принятые в продукте.
Операционный интерфейс должен помогать находить ожидающие решения запросы, запросы с истёкшим сроком действия, заблокированные из-за конфликтов, а также согласованные, но ещё не применённые. Объясняйте причину блокировки и предлагайте безопасный способ её устранить; не превращайте сбой применения в автоматическое согласование. Уведомления могут сообщать о новых задачах и решениях, но они лишь вспомогательный механизм: источником истины остаётся сохранённое состояние, доступное для проверки.
Тестируйте инварианты, права доступа и сбои
Тесты должны проверять правила, которые нельзя нарушать. Несогласованный запрос не изменяет актуальные данные; пользователь без доступа к организации не может прочитать запрос или изменить его состояние; самосогласование завершается ошибкой, если оно запрещено; согласованный запрос нельзя применить с содержимым, отличающимся от проверенного. Добавьте тесты для конечных состояний, запросов с истёкшим сроком действия и недопустимых переходов.
Проверяйте также гонки между двумя согласованиями или между согласованием и редактированием исходных данных. Смоделируйте сбои во время применения и убедитесь, что запрос не получает статус «применено», если запись не была подтверждена. Если запросы автоматически переводятся в состояние с истёкшим сроком действия фоновой задачей, проверьте безопасность повторного запуска. Такие тесты превращают бизнес-правила в проверяемые гарантии и помогают поддерживать процесс при изменении прав доступа или модели данных.
При проектировании у каждого этапа должны быть ответственный, проверяемое условие и наблюдаемый результат. Если команда не может объяснить, кто имеет право выполнять каждый переход, что происходит при конкурентном изменении и как восстановить ход принятия решения, процесс ещё нужно доработать до ввода в эксплуатацию.
