Приложение сотрудников должно отзывать доступ к рабочим данным при смене роли и увольнении

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

В нашем примере инженер видит адрес и оборудование на назначенном объекте. После перевода на другой участок прежние заявки ему больше не доступны. Должность «сервисный инженер» у него та же: проверка одной должности не учитывает смену участка и назначений.

Готовое корпоративное приложение тоже стоит проверять на этой задаче. Если оно уже получает нужные данные и выполняет ваши правила отзыва, отдельная разработка может не понадобиться. Если демонстрация заканчивается кнопкой «войти», попросите показать смену назначения на том же устройстве и в той же сессии.

Вход отвечает на вопрос «кто вы», право на документ отвечает на вопрос «что вам сейчас разрешено». Подтверждение личности, выданное до перевода, само по себе не подтверждает доступ к прежнему клиенту. OWASP требует проверять права на каждый запрос к защищённому ресурсу на стороне сервера.

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

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

Если телефон потерял связь, он не узнает об увольнении в момент кадрового решения. Сервер может уже отклонять запросы, а ранее сохранённый акт ещё открывается без сети. До разработки решите, какие данные допустимо хранить офлайн и сколько времени можно работать без повторной проверки прав.

Не обещайте дистанционно стереть произвольное приложение. Microsoft описывает выборочную очистку для приложений, подключённых к управлению Intune, с нужными политиками защиты. Выполнение зависит от запуска приложения; у команды есть состояния ожидания, ошибки и успеха. В Android Enterprise рабочий профиль отделяет рабочие приложения и данные от личных. Это разные механизмы, их применимость к вашим устройствам надо проверить.

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

Не закрывайте отзыв статусом «команда отправлена». Отдельно покажите, что сервер уже отказал, устройство ещё ждёт связи или подтвердило очистку. Просроченное ожидание должно попадать ответственному, а результат повторной проверки возвращаться в журнал. Так компания видит незавершённый отзыв, а не теряет его после увольнения.

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

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

Задание «сделать приложение для сотрудников» оставляет агенту слишком много решений о правах. В постановке задач агенту нужны исходное назначение, кадровое событие и ожидаемый отказ. Например: инженер переведён; старое вложение не скачивается; новое назначение открывается; старый акт из офлайн-очереди отклоняется.

Запишите эти условия рядом с кодом компании и включите их в правила для ИИ-агентов. В уроке «Файл правил целиком» показано, как оформлять файл правил. Для этой задачи в нём стоит закрепить источник прав, ограничения хранения и проверки, которые нельзя обходить при новом экране или интеграции.

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

Наш опыт здесь ограничен разработкой vibecoding.ru. На открытой странице машины виден её рабочий контур. Мобильное приложение сотрудников мы не внедряли; для этой статьи взяли из своих журналов ошибку, которая объясняет, зачем проверять запросы отдельно от интерфейса.

7 июля 2026 ревью обнаружило: пароль административной страницы не защищал публичные запросы, через которые она получала агрегаты. В записи предложено перенести проверку доступа к запросам. Это находка ревью, не свидетельство утечки и не доказательство, что предложенное исправление тогда было выполнено.

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

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

В подписке на разработку тариф «Все проекты» стоит 500 000 ₽ в месяц и включает три потока: в каждом одна задача в работе. Цена и условия сверены на странице 8 октября 2026. Мобильный доступ и серверные права можно развивать задачами в репозиториях компании; последовательность определяется зависимостями, а не обещанием сделать всё одновременно.

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

1. Назовите рабочее действие и владельца прав. Проверяйте назначение на конкретную заявку, а не только должность сотрудника.

2. После перевода или увольнения повторите запросы в прежней сессии. Приёмка должна показать серверный отказ, включая доступ к вложениям.

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

4. Назначьте ответственного за зависший отзыв. Ожидание связи, сигнал и повторная проверка должны оставаться в журнале.

5. Оставьте код, правила и воспроизводимые проверки в репозитории компании. Следующий выпуск должен сохранять проверенные ограничения.