Управление пользователями
Добавляйте, редактируйте и удаляйте пользователей из Вашей организации. Управляйте ролями, назначениями команд и отслеживайте индивидуальный прогресс.
Список пользователей
Страница Пользователи показывает всех участников организации в сортируемой и доступной для поиска таблице. Каждая строка отображает имя пользователя, email, команду, роль и последний вход. Отключённые пользователи помечаются встроенной маленькой плашкой DISABLED — отдельной колонки статуса нет. Кнопка Экспорт CSV вверху страницы скачивает полный список пользователей с итогами прогресса.
| Колонка | Описание |
|---|---|
| Имя | Единое поле отображаемого имени (не разделено на имя/фамилию). |
| Email для входа — используется для входа с magic-кодом. | |
| Команда | Команда, к которой принадлежит пользователь (пусто, если не назначена). |
| Роль | org_admin или learner. |
| Последний вход | Дата и время последнего входа пользователя. Пусто для пользователей, которые ещё не входили. |
Добавление пользователей
Есть два способа добавить пользователей в Вашу организацию:
Вручную
Нажмите + Добавить пользователя и введите имя пользователя, email, роль (learner или org_admin) и опционально команду. Приглашение по email не отправляется. Поделитесь URL входа с пользователем сами; они запрашивают magic-код на странице входа и входят с шестизначным кодом, который мы отправляем им по email.
SCIM-провижининг
Настройте SCIM, чтобы автоматически синхронизировать пользователей из Вашего поставщика идентификации (Okta, Azure AD). Пользователи создаются и деактивируются автоматически по мере изменения Вашего каталога.
Лимиты мест
У Вашей организации есть максимальное число мест на основе Вашего плана. Добавление пользователя сверх этого лимита не удаётся с ошибкой Seat limit reached (N). Contact support to increase. — сама страница Пользователи сегодня не показывает живой счётчик мест; используйте страницу Отчёты или публичный API GET /api/public/v1/org для чтения maxSeats по сравнению с текущим числом пользователей.
Редактирование пользователей
Нажмите на строку пользователя, чтобы открыть страницу деталей пользователя; кнопка Редактировать открывает модальное окно, позволяющее администраторам организации изменять следующие четыре свойства. Каждое поле обязательно, и редактирование действует как полная замена — чтобы оставить поле без изменений, оставьте текущее значение на месте.
| Поле | Редактируемое |
|---|---|
| Имя | Да — единое поле отображаемого имени. |
| Да — изменение не повторно отправляет никакой email. | |
| Роль | Да — learner ↔ org_admin. |
| Команда | Да — выберите команду или оставьте без назначения. |
| Пароль | Нет — поля пароля нет. Пользователи входят с magic-кодом или SSO; администраторам нечего устанавливать или сбрасывать. |
Удаление пользователей
Действие Удалить на странице деталей пользователя удаляет саму запись пользователя. После удаления человек больше не может войти. Удаление пользователя освобождает место против Вашего лимита maxSeats.
Исторические данные пользователя — результаты практических заданий, прогресс по сценариям обучения, завершения заданий, заработанные сертификаты — не стираются из базы данных, потому что эти таблицы не каскадно удаляются с записью пользователя. На практике, однако, эти данные перестают быть видимыми: каждый отчёт, таблица лидеров, верификация сертификата и страница деталей пользователя соединяются через запись пользователя, чтобы их отобразить, поэтому после исчезновения строки пользователя строки висят как сироты, которые интерфейс не показывает.
Повторное добавление того же email после удаления создаёт совершенно нового пользователя с новым внутренним id. Старые осиротевшие строки не повторно присоединяются — в админ-интерфейсе нет пути «восстановить».
Если Вы хотите сохранить видимость истории обучения пользователя для удержания доказательств, аудита соответствия или сценариев повторного найма, не используйте Удалить. Либо деактивируйте пользователя выше через SCIM (что устанавливает его как неактивного, но сохраняет запись пользователя на месте), либо просто оставьте учётную запись в покое — они не могут войти, если их почтовый ящик больше не получает magic-код.
Роли
SecureCodingHub поддерживает две роли на уровне организации:
| Роль | Может делать |
|---|---|
| Администратор организации | Управлять пользователями, командами, заданиями, просматривать панель, настраивать SSO/SCIM/SCORM |
| Учащийся | Выполнять задания, просматривать собственный прогресс, управлять настройками |
Управление местами
У Вашей организации есть лимит maxSeats, определяемый Вашим планом подписки. Сегодня на заголовке страницы Пользователи нет живого счётчика мест; если Вам нужно мониторить использование, читайте его из публичного API (GET /api/public/v1/org возвращает maxSeats) и сравнивайте с текущим числом пользователей. Свяжитесь с Вашим аккаунт-менеджером для повышения лимита, если Вам нужны дополнительные места.
Интерфейс списка пользователей
Вот как выглядит страница управления пользователями:
Модальное окно добавления пользователя
Нажатие + Добавить пользователя открывает следующую форму. Пикер ролей использует две карточки бок о бок вместо выпадающего списка:
Почему вдумчивое управление пользователями важно
Большинство организаций не замечают разрастания мест, пока оно не появится в счёте на продление. Несколько подрядчиков заканчивают проект и остаются в каталоге. Команда реорганизуется, и старое членство в команде никогда не очищается. Два инженера покидают компанию, но тикет оффбординга пропустил учебную платформу. В течение года двадцать процентов мест, за которые платит Ваша финансовая команда, принадлежат людям, которые не входят в систему, а оставшиеся учётные записи не отражают, кто фактически в команде сегодня.
Разрастание мест — это также проблема безопасности. Каждая неактивная учётная запись — это учётные данные, на которые атакующий может нацелиться через переиспользование паролей, фишинг или захват сессии. Тот же SSO, который даёт доступ к Вашей платформе ревью кода, может давать доступ и сюда, а учётная запись, за которой никто не следит, — самая лёгкая для тихой компрометации. Отношение к списку пользователей как к живому артефакту, а не бэклогу, закрывает этот пробел до того, как он станет инцидентом.
Ежеквартальный аудит сопоставления пользователь-команда
Простой ежеквартальный обзор держит реестр честным. Экспортируйте список пользователей, отфильтруйте по последнему входу старше девяноста дней и спросите линейного руководителя, должен ли каждый человек оставаться. Перепроверьте колонку Команда против Вашей HR-системы или орг-схемы — любой, чьё членство в команде больше не соответствует его фактической роли, является кандидатом на переназначение. Уделяйте особое внимание пользователям без установленной команды, так как они обычно проскальзывают мимо назначений на уровне команд и снижают проценты завершения, и никто этого не замечает.
Если Вы используете SCIM-провижининг, большая часть этой работы происходит автоматически. Членство в группах в Okta или Azure AD передаётся в сопоставление команд, а деактивация пользователя в поставщике идентификации деактивирует его в SecureCodingHub в следующем цикле синхронизации. Аудит затем становится проверкой здравомыслия, а не ручной сверкой.
Почему деактивация важна для доказательств соответствия
PCI DSS 8.1.3 и ISO 27001 элемент управления A.9.2.6 оба требуют, чтобы доступ для уволенных пользователей был оперативно отозван. Аудиторы ищут доказательства — событие с временной меткой, показывающее, когда учётная запись перестала иметь возможность входить, в идеале связанное с датой оффбординга в HR. Кнопка Удалить удовлетворяет отзыву доступа, но она также удаляет запись пользователя, что означает, что их завершённое обучение перестаёт быть видимым в отчётах — строки всё ещё существуют как сироты, но ни один интерфейс их не показывает. Если Вашему аудиту нужно, чтобы эта история продолжала отображаться как доказательство, деактивируйте через SCIM (что устанавливает учётную запись как неактивную, сохраняя запись пользователя на месте), а не используйте Удалить. Журнал аудита записывает любое действие.
Для команд, проводящих обучение безопасному программированию как часть их пака доказательств PCI DSS 6.2.2, список пользователей работает и как доказательство того, кто был в области во время периода аудита. Снимите снимок во время аудита — либо через кнопку Экспорт CSV, либо через публичный API — и сохраните его рядом с остальной частью Вашего пака доказательств.