Перейти до основного вмісту

Адміністрування сервера

Функції адміністрування сервера в ChurchApps доступні лише користувачам із дозволом Server.Admin. Ці інструменти використовуються для роботи платформи, підтримки та усунення несправностей у всіх церквах системи.

Доступ обмежено

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

Доступ до адміністрування сервера​

Користувачі з дозволом Server.Admin можуть відкрити панель адміністрування сервера з B1 Admin:

  1. Увійдіть на admin.b1.church.
  2. Відкрийте меню переходу, розгорніть Налаштування та натисніть Server Admin. (Можна також перейти безпосередньо за адресою admin.b1.church/admin.)
  3. Панель Server Admin містить розділи в лівій частині, згруповані у три категорії: Каталог (Churches, Users, Impersonate User), Операції (Background Jobs, Commons, Usage Trends) та Система (Translation Lookups, Server Health, Database Migrations).

Скидання двоетапного входу​

Якщо для користувача ввімкнено двоетапний вхід і він втратив і телефон, і резервні коди, адміністратор сервера може його вимкнути:

  1. Відкрийте розділ Users на панелі Server Admin і знайдіть користувача.
  2. Користувачі з двоетапним входом мають значок Двоетапний вхід увімкнено. Натисніть Скинути 2FA поруч із ним.
  3. Підтвердьте запит. Робіть це лише після того, як переконаєтеся, з ким ви розмовляєте.

Після цього користувач може увійти лише за паролем і знову налаштувати двоетапний вхід у своєму профілі. Скидання записується в журнал аудиту як mfa_reset. Кінцева точка: POST /membership/users/mfa/reset/:userId, для її використання потрібен дозвіл Server.Admin.

Вхід від імені користувача​

Функція входу від імені користувача дає адміністраторам сервера змогу увійти як інший користувач для підтримки та усунення несправностей. Це корисно, коли потрібно розібратися з проблемою, про яку повідомив користувач, або допомогти церкві з налаштуванням системи.

Як увійти від імені користувача​

  1. Відкрийте розділ Impersonate User на панелі Server Admin.
  2. Введіть ім'я користувача або адресу електронної пошти в полі пошуку.
  3. Натисніть Search або клавішу Enter.
  4. У результатах пошуку натисніть на користувача, від імені якого хочете увійти.
  5. Підтвердьте вхід у діалоговому вікні.
  6. Ви увійдете як цей користувач і будете перенаправлені до його облікового запису.

Важливі примітки​

  • Вхід від імені користувача створює новий сеанс із дозволами цільового користувача та його доступом до церков.
  • Ваш початковий сеанс адміністратора завершується, коли ви входите від імені іншого користувача.
  • Усі дії, виконані під час входу від імені користувача, записуються в журнал аудиту.
  • Щоб повернутися до свого облікового запису адміністратора, вийдіть і знову увійдіть зі своїми обліковими даними.
  • Використовуйте вхід від імені користувача лише тоді, коли це необхідно для підтримки, і завжди повідомляйте користувачів, коли ви отримуєте доступ до їхніх облікових записів для підтримки.

Кінцева точка API​

Функція входу від імені користувача працює через кінцеву точку /users/:userId/impersonate в API Membership. Технічні подробиці див. у розділі Кінцеві точки Membership.

Міркування щодо безпеки​

  • Для входу від імені користувача потрібен дозвіл Server.Admin. Його слід надавати обмежено і лише довіреним операторам платформи.
  • Кожна подія входу від імені користувача записується з ідентифікатором адміністратора та ідентифікатором цільового користувача.
  • Церкви не отримують сповіщень, коли відбувається вхід від імені користувача, тому варто заздалегідь визначити чіткі правила щодо того, коли і як використовувати цю функцію.
  • Розгляньте можливість документувати події входу від імені користувача у своїй системі заявок служби підтримки для забезпечення підзвітності.

Модерація Commons​

Commons — це спільна черга модерації для вмісту, який надсилають користувачі в різних продуктах. Пісні WorshipCommons, уроки Lessons.church, шаблони FreeShow і шаблони конструктора веб-сайтів B1 проходять через одну чергу, а не через окремі інструменти перевірки для кожного продукту.

Доступ до Commons​

  1. Перейдіть на вкладку Commons на панелі Server Admin.
  2. Ви побачите три підвкладки: Черга, Звіти та Ресурси.

Обмежена роль редактора музики також може бачити вкладку «Черга», але не може схвалювати подання, які змінюють права або ліцензування пісні.

Черга​

У черзі відображаються всі очікувані подання з усіх продуктів, які можна фільтрувати за продуктом і типом ресурсу. У кожному рядку вказано, чи є подання новим ресурсом, редагуванням від його початкового автора чи редагуванням від третьої сторони, а також історію схвалень автора подання та час очікування (позначається, коли перевищує 72 години).

Натисніть Review, щоб відкрити панель з порівнянням полів, попереднім переглядом файлів і вбудованим переглядом елемента лише для читання. Використовуйте клавіші a і r, щоб схвалити або відхилити подання, а j і k, щоб перейти до наступного або попереднього подання, не закриваючи панель. Щоб відхилити подання, потрібно вибрати причину (наприклад, якість, дублікат, ліцензування, ccli, ai або не за темою) і залишити примітку.

Звіти​

Вкладка «Звіти» обробляє скарги на порушення авторських прав і скарги щодо політики чи якості, подані на вже опубліковані ресурси. Вони поділені на окремі черги «Авторські права» та «Політика й інше», а також на історію вирішених. Щоб почати роботу зі скаргою, призначте її собі, а потім вирішіть її, вказавши результат (підтверджено, відхилено або дублікат) і дію (немає, зняти з публікації або видалити).

Ресурси​

Вкладка «Ресурси» — це пошуковий перегляд опублікованого вмісту з діями: Feature (виділити ресурс на головній сторінці продукту), Unpublish/Republish (зняти з публікації або опублікувати знову) або Remove (видалити з вказанням причини: авторські права або політика).

Для пісень ця вкладка також визначає, чи пісня стає готовою до неділі та чи може з'являтися в пошуку пісень B1 Admin у церкви. Рецензент відкриває ресурс і позначає кожну опубліковану тональність як Прослухано, після того як прослухав її і переконався, що ноти, акорди та слайди на місці. Пісня стає готовою до неділі лише тоді, коли позначено всі тональності.

інформація

Модерація Commons доступна лише співробітникам. Окремі церкви ніколи не бачать цю чергу. Єдине місце, де B1 Admin окремої церкви працює з даними Commons, — це розділ «WorshipCommons — безкоштовно» в пошуку пісень. Там відображаються лише пісні, які вже пройшли цей процес перевірки.

Щоб дізнатися про базову модель даних і життєвий цикл подань, перегляньте сторінку Архітектура Content Commons.

Схвалення електронної пошти групи​

Церкви не можуть надсилати авторські листи (електронну пошту групи, наступні повідомлення з форм, листи робочих процесів і запрошення до облікових записів), доки адміністратор сервера не схвалить їх. Це запобігає тому, щоб церкви, зареєстровані ботами, використовували спільну адресу відправлення ChurchApps для спаму.

  1. Відкрийте вкладку Churches на панелі Server Admin.
  2. Кожна церква має позначку Group Email: Approved (зелена) або Not approved (з контуром).
  3. Натисніть позначку та підтвердьте, щоб схвалити церкву або скасувати схвалення.

Співробітники церков запитують схвалення кнопкою Request review у діалоговому вікні «Надіслати електронний лист» в B1 Admin. Запит надсилається на адресу служби підтримки і містить назву церкви, ідентифікатор, дату реєстрації, місцезнаходження та ім'я особи, яка подала запит. Церква може надіслати один запит на тиждень. Щодо денного ліміту та автоматичної паузи після повернених листів і скарг див. розділ Обмеження на листи, які пише церква.

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

Робочий процес Deploy Prod застосовує очікувані міграції самостійно. Розміщені бази даних приймають підключення лише з мережі API, тому runner GitHub до них не дістається. Натомість одразу після serverless deploy робочий процес викликає Lambda migrate API (api-Prod-migrate). Вона виконує очікувані міграції всіх модулів тим самим runner, що й ця вкладка, і завершує розгортання з помилкою, якщо будь-який модуль видає помилку або його відхилено. Rollback Prod відкочує лише код Lambda; застосовані міграції залишаються застосованими. Вкладка Міграції бази даних призначена для перевірки статусу, запуску того, що не було застосовано під час розгортання (наприклад, у демо-середовищі, де розгортання не виконує міграції), і для фіксації базових версій модулів без історії. (Встановлення Docker на власному сервері й далі виконують міграції автоматично під час запуску контейнера API.)

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

  • Запустити очікувані міграції застосовує всі очікувані міграції по одному модулю, у правильному порядку. Процес зупиняється на першій помилці та показує, що було застосовано для кожного модуля.
  • Модуль із позначкою Немає історії має базу даних, створену до відстеження міграцій. Такі модулі ніколи не запускаються автоматично, адже це призвело б до повторного виконання старих міграцій даних у робочих таблицях. Натомість натисніть Перевірити схему для цього модуля. API порівнює таблиці, стовпці та індекси, які створює кожна міграція, із поточною базою даних, і позначає кожну міграцію як Уже застосовано, Відсутні, Частково застосовано або Лише дані. Перевірка нічого не змінює.
  • У результатах перевірки Записати як уже застосовані додає виявлені міграції в історію міграцій, але не запускає їх (після підтвердження). Записуються всі міграції до останньої позначеної Уже застосовано, включно з міграціями Лише дані в цьому діапазоні. Міграції Відсутні залишаються очікуваними, і їх можна потім звичайним способом запустити кнопкою Запустити очікувані міграції.
  • Міграція Частково застосовано блокує запис. Якщо міграцію безпечно запустити повторно (спершу прочитайте її), позначте Повторний запуск, щоб вона залишилася очікуваною і виконалася знову з початку.

Панель Server Admin і 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.

Пов'язані сторінки​