メインコンテンツに移動

サーバー管理

ChurchAppsのサーバー管理機能は、Server.Admin権限を持つユーザーだけが利用できます。これらのツールは、システム内のすべての教会を対象とするプラットフォームの運用、サポート、トラブルシューティングに使用します。

アクセス制限

このページで説明する機能にはServer.Admin権限が必要です。通常の教会管理者は利用できません。プラットフォームの運営者とサポート担当者のみを対象としています。

サーバー管理へのアクセス​

Server.Admin権限を持つユーザーは、B1 Adminからサーバー管理パネルにアクセスできます。

  1. admin.b1.churchにログインします。
  2. ジャンプメニューを開き、設定を展開してServer Adminをクリックします。(admin.b1.church/adminに直接アクセスすることもできます。)
  3. サーバー管理パネルでは、左側に各セクションが次の3つのグループに分けて表示されます。ディレクトリ(Churches、Users、Impersonate User)、運用(Background Jobs、Commons、Usage Trends)、システム(Translation Lookups、Server Health、Database Migrations)です。

2段階認証のリセット​

ユーザーが2段階認証を有効にしていて、電話とバックアップコードの両方を紛失した場合は、サーバー管理者が2段階認証を無効にできます。

  1. サーバー管理パネルのUsersセクションを開き、対象ユーザーを検索します。
  2. 2段階認証を有効にしているユーザーにはTwo-factor onのバッジが表示されます。その横のReset 2FAをクリックします。
  3. 確認のプロンプトで操作を確定します。本人であることを確認してから実行してください。

その後、ユーザーはパスワードだけでログインでき、プロフィールから2段階認証を設定し直せます。リセットはmfa_resetとして監査ログに記録されます。エンドポイントはPOST /membership/users/mfa/reset/:userIdで、Server.Admin権限が必要です。

ユーザーのなりすまし​

なりすまし機能を使うと、サーバー管理者はサポートやトラブルシューティングのために、別のユーザーとしてログインできます。ユーザーから報告された問題を調査する場合や、教会がシステムを設定するのを手伝う場合に役立ちます。

ユーザーになりすます方法​

  1. サーバー管理パネルのImpersonate Userセクションを開きます。
  2. 検索欄にユーザーの名前またはメールアドレスを入力します。
  3. Searchをクリックするか、Enterキーを押します。
  4. 検索結果から、なりすますユーザーをクリックします。
  5. 表示されるダイアログでなりすましを確認します。
  6. そのユーザーとしてログインされ、ユーザーのアカウントに移動します。

重要な注意事項​

  • なりすましを行うと、対象ユーザーの権限と教会へのアクセス権を持つ新しいセッションが作成されます。
  • 別のユーザーになりすますと、元の管理者セッションは終了します。
  • なりすまし中に行ったすべての操作は、監査証跡に記録されます。
  • 管理者アカウントに戻るには、ログアウトしてから自分の認証情報でログインし直します。
  • なりすましは、サポート上どうしても必要な場合にのみ使用してください。ユーザーのアカウントにサポート目的でアクセスする場合は、必ずユーザーに知らせてください。

APIエンドポイント​

なりすまし機能は、Membership APIの/users/:userId/impersonateエンドポイントで動作します。技術的な詳細はMembershipエンドポイントをご覧ください。

セキュリティに関する考慮事項​

  • なりすましにはServer.Admin権限が必要です。この権限は慎重に付与し、信頼できるプラットフォーム運営者だけに与えてください。
  • すべてのなりすまし操作は、管理者のユーザーIDと対象ユーザーのユーザーIDとともに記録されます。
  • なりすましが行われても教会には通知されません。そのため、この機能をいつ、どのように使うかについて明確な方針を定めておいてください。
  • なりすましの操作は、説明責任を果たすためにサポートチケットのシステムに記録しておくことをお勧めします。

Commonsのモデレーション​

Commonsは、製品をまたいでユーザーが投稿したコンテンツの共有モデレーションキューです。WorshipCommonsの楽曲、Lessons.churchのレッスン、FreeShowのテンプレート、B1ウェブサイトビルダーのテンプレートは、製品ごとに別々のレビューツールを使うのではなく、すべてこの同じキューを経由します。

Commonsへのアクセス​

  1. サーバー管理パネルのCommonsタブに移動します。
  2. Queue、Reports、Assetsの3つのサブタブが表示されます。

権限が制限された音楽エディターの役割を持つユーザーも、Queueタブを表示できます。ただし、楽曲の権利やライセンスを変更する投稿は承認できません。

Queue​

Queueには、すべての製品にわたる保留中の投稿がすべて表示されます。製品とアセットの種類で絞り込めます。各行には、投稿が新しいアセットか、元の作成者による編集か、第三者による編集かが表示されます。あわせて投稿者の承認実績と、待機している時間も表示されます。72時間を超えて待機している投稿には、フラグが付きます。

Reviewをクリックすると、フィールドごとの差分、ファイルのプレビュー、アイテムの読み取り専用プレビューを含むドロワーが開きます。aキーとrキーで承認・却下できます。jキーとkキーを使うと、ドロワーを閉じずに次または前の投稿に移動できます。却下する場合は、理由(例:品質、重複、ライセンス、CCLI、AI、トピック外)を選択し、メモを入力する必要があります。

Reports​

Reportsタブでは、公開済みのアセットに対して寄せられた著作権報告とポリシー・品質に関する報告を処理します。報告は「著作権」と「ポリシーその他」の2つのキューに分かれており、対応済みの履歴は「Resolved」で確認できます。対応を始めるには報告を自分に割り当てます。その後、対応結果(支持、却下、重複)と処置(なし、公開停止、削除)を選んで解決します。

Assets​

Assetsタブでは、公開済みのコンテンツを検索して閲覧できます。アセットに対して、Feature(製品のホームページで強調表示する)、Unpublish/Republish(公開停止/再公開)、Remove(著作権またはポリシーの理由を添えて削除)の操作を行えます。

楽曲の場合は、このタブで楽曲を日曜日対応済みにし、教会のB1 Adminの楽曲検索に表示できるようにします。レビュー担当者はアセットを開き、公開されている各キーを聴き終えて、楽譜、コード、スライドがすべて揃っていることを確認したら、そのキーをListenedにチェックします。すべてのキーにチェックが付いて初めて、楽曲は日曜日対応済みになります。

情報

Commonsのモデレーションはサーバー管理者だけが行います。個々の教会がこのキューを見ることはありません。個々の教会のB1 AdminがCommonsのデータに触れるのは、楽曲検索の「WorshipCommons — 無料」セクションだけです。このセクションに表示されるのは、このレビュー過程をすでに通過した楽曲のみです。

基盤となるデータモデルと投稿の流れについては、Content Commonsのアーキテクチャのページをご覧ください。

グループメールの承認​

教会は、サーバー管理者が承認するまで、教会が作成したメール(グループメール、フォームのフォローアップ、ワークフローのメール、アカウントへの招待)を送信できません。これは、ボットで登録された教会がChurchAppsの共有送信アドレスを使ってスパムを送るのを防ぐための措置です。

  1. サーバー管理パネルのChurchesタブを開きます。
  2. 各教会にはGroup Emailのチップが表示されます。Approved(緑)またはNot approved(枠線のみ)のいずれかです。
  3. チップをクリックし、確認して教会を承認するか、承認を取り消します。

教会のスタッフは、B1 Adminのメール送信ダイアログにあるRequest reviewボタンを使って承認を依頼します。依頼はサポート用のアドレスにメールで届き、教会の名前、ID、登録日、所在地、依頼者の情報が記載されます。教会が依頼できるのは週に1回です。1日あたりの送信上限と、バウンスや苦情による自動停止については、教会が作成したメールの制限をご覧ください。

データベースのマイグレーション​

Deploy Prodワークフローは、保留中のマイグレーションを自分で適用します。ホスト型のデータベースはApiのネットワーク内からの接続しか受け付けないため、GitHubのランナーからは到達できません。そこで、ワークフローはserverless deployの直後にApiのmigrate Lambda(api-Prod-migrate)を呼び出します。この Lambdaは、このタブと同じ仕組みで各モジュールの保留中のマイグレーションをすべて実行し、いずれかのモジュールでエラーが発生するか実行が拒否された場合はデプロイを失敗させます。Rollback ProdはLambdaのコードだけを元に戻します。適用済みのマイグレーションは適用されたままです。Database Migrationsタブは、ステータスの確認、デプロイでは実行されなかったマイグレーションの実行(例えば、デプロイ時にマイグレーションを行わないデモ環境)、マイグレーション履歴のないモジュールのベースライン設定に使用します。(セルフホストのDockerインストールでは、Apiコンテナの起動時にマイグレーションが自動的に実行されます。)

このタブには、現在の環境と、モジュール(membership、attendance、givingなど)ごとに1行ずつ、ステータス、適用済みと保留中のマイグレーションの数、最後に適用されたマイグレーションが表示されます。

  • 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にチェックを入れます。そうすると保留のままになり、先頭から再度実行されます。

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のみが利用できます。

関連ページ​