Перейти к основному содержимому

Администрирование сервера

Функции администрирования сервера в ChurchApps доступны только пользователям с правом Server.Admin. Эти инструменты используются для эксплуатации платформы, поддержки и устранения неполадок во всех церквях системы.

Доступ ограничен

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

Доступ к администрированию сервера​

Пользователи с правом Server.Admin могут открыть панель администрирования сервера из B1 Admin:

  1. Войдите на admin.b1.church
  2. Откройте меню перехода, разверните Settings и нажмите Server Admin. (Также можно сразу перейти на admin.b1.church/admin.)
  3. На панели администрирования сервера разделы перечислены слева в трёх группах: Directory (Churches, Users, Impersonate User), Operations (Background Jobs, Commons, Usage Trends) и System (Translation Lookups, Server Health, Database Migrations)

Сброс двухфакторного входа​

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

  1. Откройте раздел Users на панели администрирования сервера и найдите пользователя.
  2. У пользователей с двухфакторным входом отображается значок Two-factor on. Нажмите Reset 2FA рядом с ним.
  3. Подтвердите запрос. Делайте это, только убедившись, с кем вы общаетесь.

После этого пользователь может войти, используя только пароль, и заново настроить двухфакторный вход в своём профиле. Сбросы записываются в журнал аудита как mfa_reset. Эндпоинт — POST /membership/users/mfa/reset/:userId, он требует Server.Admin.

Имперсонация пользователя​

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

Как выполнить имперсонацию пользователя​

  1. Откройте раздел Impersonate User на панели администрирования сервера
  2. Введите имя или адрес электронной почты пользователя в поле поиска
  3. Нажмите Search или Enter
  4. Из результатов поиска выберите нужного пользователя
  5. Подтвердите имперсонацию в появившемся диалоге
  6. Вы войдёте под этим пользователем и будете перенаправлены в его учётную запись

Важные замечания​

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

Эндпоинт API​

Функция имперсонации опирается на эндпоинт /users/:userId/impersonate в Membership API. Технические подробности см. в Эндпоинты Membership.

Вопросы безопасности​

  • Имперсонация требует права Server.Admin — это право следует выдавать скупо и только доверенным операторам платформы
  • Все события имперсонации фиксируются с ID администратора и ID целевого пользователя
  • Церкви не уведомляются при имперсонации, поэтому установите чёткие правила, когда и как пользоваться этой функцией
  • Имеет смысл документировать события имперсонации в системе тикетов поддержки для подотчётности

Модерация Commons​

Commons — это общая очередь модерации пользовательского контента для всех продуктов: песни WorshipCommons, уроки Lessons.church, шаблоны FreeShow и шаблоны конструктора сайтов B1 проходят через одну очередь, а не через отдельные инструменты проверки каждого продукта.

Доступ к Commons​

  1. Перейдите на вкладку Commons на панели администрирования сервера.
  2. Вы увидите три подвкладки: Queue, Reports и Assets.

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

Queue​

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

Нажмите Review, чтобы открыть панель с построчными различиями, предпросмотром файлов и встроенным предпросмотром элемента только для чтения. Для одобрения или отклонения используйте сочетания клавиш a / r, а для перехода к следующей или предыдущей отправке без закрытия панели — j / k. При отклонении нужно выбрать причину (например, quality, duplicate, licensing, ccli, ai или off-topic) и добавить примечание.

Reports​

Вкладка Reports обрабатывает жалобы на нарушение авторских прав и политики/качества, поданные на уже опубликованные ресурсы; они разделены на отдельные очереди Copyright и Policy & Other, а также историю Resolved. Возьмите жалобу в работу, а затем закройте её с решением (upheld, dismissed или duplicate) и действием (none, unpublish или remove).

Assets​

Вкладка Assets — это поисковый просмотр опубликованного контента с действиями: Feature (выделить ресурс на главной странице продукта), Unpublish / Republish или Remove (с причиной, связанной с авторскими правами или политикой).

Для песен именно здесь песня становится Sunday-ready и может появляться в поиске песен в B1 Admin церкви: проверяющий открывает ресурс и отмечает каждую опубликованную тональность как Listened, когда прослушал её и убедился, что ноты, аккорды и слайды на месте. Песня становится Sunday-ready только тогда, когда отмечены все тональности.

Информация

Модерация Commons доступна только сотрудникам — отдельные церкви никогда не видят эту очередь. Единственное место, где B1 Admin церкви затрагивает данные Commons, — раздел «WorshipCommons — free» в поиске песен, в котором показываются только песни, уже прошедшие эту проверку.

Подробнее о базовой модели данных и жизненном цикле отправки см. на странице Архитектура Content Commons.

Одобрение групповой почты​

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

  1. Откройте вкладку Churches на панели администрирования сервера.
  2. У каждой церкви есть значок Group Email: Approved (зелёный) или Not approved (контурный).
  3. Нажмите на значок и подтвердите, чтобы одобрить церковь или отозвать одобрение.

Сотрудники церкви запрашивают одобрение кнопкой Request review в диалоге Send Email в B1 Admin. Запрос отправляется на адрес поддержки и содержит название церкви, её ID, дату регистрации, местоположение и того, кто запросил. Церковь может отправлять один запрос в неделю. Дневной лимит и автоматическую паузу при отскоках и жалобах см. в разделе Ограничения писем, написанных церковью.

Миграции базы данных​

Workflow Deploy Prod применяет ожидающие миграции сам. Размещённые базы данных принимают подключения только изнутри сети API, поэтому раннер GitHub до них не дотянется; вместо этого сразу после serverless deploy workflow вызывает Lambda migrate API (api-Prod-migrate), которая выполняет ожидающие миграции каждого модуля тем же раннером, что и эта вкладка, и проваливает развёртывание, если какой-либо модуль завершился ошибкой или отказал. Rollback Prod откатывает только код Lambda; применённые миграции остаются применёнными. Вкладка Database Migrations нужна для проверки статуса, для запуска того, что не запустило развёртывание (например, в демо-окружении, где развёртывание не выполняет миграции), и для фиксации базовой точки модулей без истории. (Самостоятельно развёрнутые установки Docker по-прежнему выполняют миграции автоматически при запуске контейнера API.)

На вкладке показано текущее окружение и по одной строке на каждый модуль (membership, attendance, giving и т. д.) со статусом, количеством применённых и ожидающих миграций и последней применённой миграцией.

  • Run Pending Migrations применяет все ожидающие миграции по одному модулю за раз, по порядку. Она останавливается на первой ошибке и показывает, что было применено для каждого модуля.
  • Модуль с пометкой No history имеет базу данных, которая старше отслеживания миграций. Она никогда не запускается автоматически, потому что это повторно прогнало бы старые миграции данных по рабочим таблицам. Вместо этого нажмите Check Schema для этого модуля. API сравнит таблицы, столбцы и индексы, которые создаёт каждая миграция, с рабочей базой данных и пометит каждую миграцию как Already applied, Missing, Partly applied или Data only. Проверка ничего не меняет.
  • В результатах проверки Record as Already Applied записывает найденные миграции в историю миграций без выполнения (после подтверждения). Записывается всё до последней миграции Already applied, включая Data only в этом диапазоне; Missing остаются ожидающими и затем могут быть выполнены обычным способом через Run Pending Migrations.
  • Миграция Partly applied блокирует фиксацию. Если миграцию безопасно запустить повторно (сначала прочитайте её), отметьте Re-run, чтобы она осталась ожидающей и выполнилась заново с начала.

Панель администрирования сервера и CLI (yarn migrate:up) используют один и тот же мигратор Kysely и таблицу kysely_migration, поэтому они всегда согласованы в том, что уже применено. Поддерживающие эндпоинты: GET /membership/serverHealth/migrations, POST /membership/serverHealth/migrations/:module/run, GET .../:module/detect и POST .../:module/baseline — все только для Server.Admin.

Связанные страницы​