サーバー管理 > アイテムのタイプ属性 > ドキュメントの設定 > ドキュメント ロック > 変更管理とドキュメント ロック
  
変更管理とドキュメント ロック
ドキュメント ロックを使用してドキュメント レベルで変更管理を実行できます。この管理は、ドキュメントの構造や特定のフィールドなど、ドキュメント ロックで制御される領域に制限されます。ここでは、ドキュメント ロックを使用する変更管理の実装例を示します。
この例の目的のため、この実装に関して次の点を前提としています。
ドキュメントのワークフローには、「制限」と呼ばれる状態が含まれます。
ドキュメント アイテムには、編集不可能な「担当ユーザー」フィールドがあります。
「変更依頼」と呼ばれるアイテム タイプが存在し、ドキュメントに対する変更の要求と承認を行うために使用されます。
変更依頼のワークフローには、「サブミット」、「開発中」、「完了」と呼ばれる状態が含まれます。
変更依頼アイテムには、編集可能な「担当ユーザー」フィールドがあります。ドキュメントが「開発中」状態の場合は、このフィールドに値を指定する必要があります。
変更依頼のタイプのアイテムは、ドキュメントに関連付けることができます。
次のドキュメント ロックの側面が構成されています。
ロックは、「制限」状態の場合に、このタイプのドキュメントを編集するために必要です。
「担当ユーザー」フィールドのユーザーのみがドキュメントをロックできます。
次の 2 つの規則ベースのプレイベント トリガーがあります。
最初は、変更依頼が「開発中」状態に入ったときにのみ実行し、その変更依頼はドキュメントに関連付けられます。
2 番目は、変更依頼が「完了」状態になったときにのみ実行し、その変更依頼はドキュメントに関連付けられます。
ここで、Dale というユーザーが変更管理下にあるドキュメントに変更を加える場合を例に示します。
1. ドキュメントは現在、「制限」状態になっています。つまり、ユーザーがロックで制御されるドキュメントの構造やフィールドを変更する前に、このドキュメントをロックする必要があります。
2. Dale は、ドキュメントをロックする必要がある変更を加えたいと考えています。そこで、Dale は変更依頼を作成し、これをドキュメントに関連付けます。
3. 変更依頼が承認されると、変更依頼の「担当ユーザー」フィールドを設定することにより、実装のため、Dale に変更依頼が割り当てられます。
4. Dale は変更依頼をレビューし、状態を「開発中」に移行します。
5. 最初のイベント トリガーが実行され、次の処理が行われます。
a. ドキュメントがロックされていないことと、ドキュメントの「担当ユーザー」フィールドが記入されていないことが確認されます。どちらかが満たされていない場合、トリガーは中止され、この時点で「開発中」への変更依頼の移行は許可されません。別のユーザーが現在ドキュメントで作業しています。
b. ドキュメントがロックされておらず、そのドキュメントの「担当ユーザー」フィールドが空の場合、トリガーは次の 2 つのアクションを実行します。
変更依頼の「担当ユーザー」フィールドの値 (Dale) をドキュメントの「担当ユーザー」フィールドにコピーします。
担当ユーザー (Dale) のドキュメントが自動的にロックされます。
6. このドキュメントは現在、Dale がドキュメントに必要な変更を加えて変更依頼を実行できるようにロックされています。
7. すべての変更が終了したら、Dale は変更依頼を「完了」状態に移行します。
8. 2 番目のイベント トリガーが実行されます。ドキュメントのロックを解除し、ドキュメントの「担当ユーザー」フィールドを消去します。
Dale の変更が完了します。Dale または別のユーザーが同じドキュメントに次の変更を行う場合は、別の変更依頼が必要です。