共同編集の管理
共同編集はチームワークを次のレベルに引き上げます。このページでは、共同編集の管理に必要なあらゆる情報について説明します。
チームがソフトウェア要件、ミーティング議事録、ふりかえり、およびその他のあらゆる Confluence ページでリアルタイムで共同作業を行う方法を「共同編集」でご確認ください。
Synchrony について
共同編集は、リアルタイムでデータを同期する Synchrony によって動作しています。Confluence は Synchrony を管理するので、管理者が手動で操作する必要はありません。
Synchrony は既定ではポート 8091 で実行されます。内部 Synchrony プロキシを設置しているのは、この追加ポートを開く必要がないようにするためです。
Synchrony に接続する方法は、環境および Confluence ライセンスによって異なります。「Confluence および Synchrony で利用可能な設定」を参照してください。
To see your collaborative editing and Synchrony setup, head to
Error rendering macro 'excerpt-include'
ユーザー 'null' にはこのページを表示する権限がありません。
編集モードの変更
編集モードは、サイトのすべてのユーザーの編集エクスペリエンスを決定します。共同編集を有効化または無効化するには、次の手順を実行します。
編集モードを変更するには、次の手順を実行します。
- 移動 > Collaborative editing.
Error rendering macro 'excerpt-include'
ユーザー 'null' にはこのページを表示する権限がありません。
- [モードの変更] を選択します。
- [On] または [Off] を選択し、[変更] を選択します。
編集モードの変更は簡単な操作ではありません。各モードの動作を理解しておくことをおすすめします。
| モード | 意味 |
|---|---|
| オン | このモードでは、ページの共有された下書きをチームで同時に編集し、お互いの変更をリアルタイムで確認できます。 これが推奨される編集モードです。 |
| オフ | このモードでは、チーム メンバーはページ内の自分の下書きのみを編集できます。保存時、Confluence は競合のマージを試みます。すべてのエクスペリエンスを提供するために、共同編集を有効にすることを検討してください。 このモードは、ご使用の環境で Synchrony を正常に実行できない場合や、共同編集が適当でないと判断された場合 (共同編集を使用できない監査要件があるなど) に役立ちます。 既存の共有下書きの編集や未公開の変更を再開することはできないため、共有下書きがある場合は、共同編集を無効にする前にユーザーに公開を促すことをおすすめします。 |
モードを変更した場合の既存の下書きへの影響
ユーザーは、自分のプロファイルの [下書き] ページから、既存の個人用下書きと共有下書きにいつでもアクセスできます。下書きの編集を再開できるかどうかは、編集のモードによって異なります。
共同編集が有効化されている場合、ユーザーは個人用下書きまたは共有下書きの編集を破棄または再開できます。個人用下書きは、ユーザーが編集を再開すると共有下書きに変換されます。
共同編集が無効化されている場合、ユーザーは個人用下書きの編集を破棄または再開できます。既存の共有下書きの編集を再開することはできませんが、それらの下書きの内容を表示し、コピーすることはできます。
共有下書きは、共同編集が有効かつ以下の場合に、ユーザーの [下書き] ページにのみ表示されます。
- 下書きを作成したが、まだ公開していない
- 公開済みのページを編集したが、その変更内容を公開していない
同時編集の上限
最大 12 人のユーザーが同時にページを編集することができます。つまり、すでに 12 人のユーザーがページを編集している場合、新しいユーザーはエディタを開くことができず、それらのユーザーがエディタを離れるまで待つ必要があります。
管理者はシステム プロパティを使用して、この制限を増やしたり減らしたりすることができます。多数のユーザーが編集しているときにパフォーマンスの問題が発生した場合、この制限を減らすことをおすすめします。
監査に関する考慮事項
弊社では、一部のお客さまにとって監査が主要な考慮事項であることを理解しています。現時点で、共同編集に関連する緻密な監査機能は提供していません。 すべてのページ変更は、それぞれの変更を行ったユーザーではなく、そのページの公開者に帰属します。
お客様のサイトでこれが問題になる場合、現時点ではサイトの共同編集をオフにすることをおすすめします。
未公開の下書きのバージョン履歴は保存不可
共同編集は常に保存されていますが、未公開の変更のバージョンは保存されません。古いページ バージョンを復元する場合、既存の公開済みバージョンへのロールバックのみが可能です。未公開の変更は、旧バージョンを復元すると失われます。
匿名ユーザーが行った編集の可視化
匿名ユーザーにページの追加権限を付与し、さらに Confluence の使用グローバル権限が付与されている場合、以下に注意する必要があります。
ページのすべての未公開の変更を匿名ユーザーが行った場合、エディタを閉じたときやページを公開した際にアラートは送信されません。つまり、ログイン済みのユーザーはページへの変更を認識せずにそれらを意図せず公開してしまう可能性があります。
変更自体はページに表示されますが、変更を加えたユーザーがログインしていない場合、通常の警告ダイアログは表示されません。
ログイン済みのユーザーと匿名ユーザーの両方による未公開の変更があった場合、警告メッセージが表示されますが、ログイン済みのユーザーのみがダイアログに表示されます。そのダイアログの変更を表示すると、すべてのユーザー (匿名を含む) による変更が含まれます。
プロキシと SSL の考慮事項
Synchrony に接続する方法は、環境によって異なります。ほとんどの Confluence サイトはリバース プロキシの背後で (多くの場合は SSL とともに) 実行されています。ここでは、自身の環境に適した設定を特定するのに役立つ情報や、サイトで共同編集を使用するために環境で必要な変更について説明します。
SSL
Synchrony は別の JVM で実行されており、直接 HTTPS 接続をサポートしていません。リバース プロキシを使用しない場合、Tomcat で SSL を終了する必要があります。リバース プロキシやロード バランサを使用する場合、リバース プロキシやロード バランサで SSL を終了する必要があります。
詳細な図と例については、「Confluence および Synchrony で利用可能な設定」を参照してください。
プロキシ
リバース プロキシの背後で Confluence を実行している場合、「Confluence および Synchrony で利用可能な設定」で、Confluence および Synchrony セットアップがプロキシに与える影響についてのガイダンスをご確認ください。
詳細な図と例、プロキシ構成ファイル例へのリンクについては、「Confluence および Synchrony で利用可能な設定」を参照してください。
WebSocket
最善の結果を得られるよう、ロード バランサとプロキシで WebSocket 接続を許可する必要があります。ユーザーが WebSocket に接続できない場合、Confluence は XHR (XML HTTP Request) にフォールバックして、正常にページを編集できるようにします。
XHR フォールバックはデフォルトで有効ですが、必要に応じて (Confluence に渡された) システム プロパティを使用して無効化することができます。これを変更する必要はありません。
Synchrony 設定の変更
Confluence UI を使用して Synchrony 設定を変更することはできません。ほとんどの場合、デフォルト設定に変更を加える必要はありません。
Synchrony を実行するポートや利用可能なメモリの最大量を変更する必要がある場合は、システム プロパティや start-synchrony スクリプト (独自の Synchrony クラスタを実行している場合) で行うことができます。
詳しくは「Synchrony を設定する」を参照してください。
Synchrony の起動と停止
Synchrony が Confluence で管理されている場合 (推奨)、Confluence は起動時に Synchrony を自動的に立ち上げます。また、Confluence の共同編集管理画面から Synchrony を再起動することもできます。
クラスタで Synchrony をスタンドアロンで実行している場合、各 Synchrony ノードで start-synchrony.sh または start-synchrony.bat スクリプトを使用します。プロセス ID (PID) ファイルが Synchrony ディレクトリ内に作成されます。
Synchrony を停止するには、同様に stop-synchrony.sh または stop-synchrony.bat を実行します。これにより、Synchrony ディレクトリで開始スクリプトが作成した PID ファイルが破壊されます。start-synchrony スクリプトで PID ファイルの保存先をカスタマイズした場合、stop-synchrony スクリプトでもこれを更新する必要があります。
Synchrony を起動できない場合、Synchrony ディレクトリに既存の PID ファイルがないことを確認します。
Synchrony の監視
To check if Synchrony is running, go to
Error rendering macro 'excerpt-include'
ユーザー 'null' にはこのページを表示する権限がありません。
Confluence をクラスタで実行している場合は、クラスタリング画面から各ノードの Synchrony のステータスを確認できます。
移動
Error rendering macro 'excerpt-include'
ユーザー 'null' にはこのページを表示する権限がありません。
ここから、Synchrony のステータス、モード、および Confluence が接続している URL を確認できます。Confluence で Synchrony を管理すると次のように表示されます。
すべての Confluence ノードは同じ Synchrony モードを使用する必要があります例えば、1 つのノードでは管理された Synchrony を使用し、別のノードではスタンドアロンの Synchrony クラスタに接続するようなことはできません。
Confluence と Synchrony の間の接続状態は、ATST プラグイン 1.53.2以降に付属しているヘルス チェックを使用して追跡できます。Synchrony の接続ヘルス チェックを利用できるようにするには、ATST プラグインをバージョン 1.53.2 以降にアップグレードしてください。ヘルス チェックの詳細
Synchrony ログにアクセスする
Synchrony が Confluence で管理されている場合 (推奨)、Synchrony ログは、Confluence アプリケーション ログとともに <local-home>/logs directory に保存されます。
スタンドアロンの Synchrony をクラスタで実行している場合、Synchrony ログは、各ノード (開始および終了スクリプトを実行する場所) の Synchrony ディレクトリに保存されます。
ログ レベルの変更方法については、「Synchrony の設定」を参照してください。
Synchrony データの管理
各ページとブログ投稿には独自の Synchrony 変更履歴があり、そのページまたはブログ投稿に対するすべての編集のグラフが含まれます。ビジーな Confluence サイトでは、Synchrony の変更履歴を格納するデータベース テーブルが非常に急速に成長することがあります。変更履歴にはすべての変更が格納されるため、関連するページが削除された後でも、個人を特定できる情報が保持されることがあります。
Synchrony データを削除するための 2 つのスケジュール ジョブを提供しています。
- Synchrony データのエビクション (ソフト)
- Synchrony データのエビクション (ハード)
ソフト エビクション ジョブは、バックグラウンドで定期的に実行されます。ハード エビクション ジョブは、Synchrony データをより積極的に削除する必要がある場合に使用でき、デフォルトでは無効になっています。
これらのジョブの仕組みの詳細については「Synchrony データを削除する方法」を参照してください。