作業スペースにおけるライフサイクルの定義

接続されたワークスペース内の各アイテムは、一連のリビジョンで構成されており、データが変更されてコミット/アップロード/リリースされるたびに、新しいリビジョンが新しいデータを収容するために使用されます。したがって、リビジョンはアイテムが変更を受けるにつれての進捗を反映します。または、逆に言えば、アイテムによって表されるデータエンティティが変更された場合、その変更を反映するためにリビジョンを増やす必要があります。

アイテムのリビジョンについては、そのリビジョンの現在の状態、つまりその「生涯」のどの段階に達しているかを反映することも重要です。この状態はアイテムリビジョンのライフサイクルとして参照されます。

ライフサイクルにより、企業はビジネスの観点からアイテムを管理し、企業のポリシーと実践に従って管理できます。このライフサイクル情報により、ワークスペース内のアイテムを使用する必要がある人々（リリースされた設計の「ビルディングブロック」の再利用を検討している設計者から、ボードを製造および組み立てるためにデータが必要なサプライチェーンまで）は、アイテムのリビジョンがその「生涯」のどの段階に達しているか、そしてそれが安全に使用できるものであるかを一目で確認できます。

ライフサイクルのモデリング

異なる組織は設計アイテムのライフサイクルをわずかに異なる方法でモデル化またはラベル付けするかもしれませんが、すべて同様のテーマに従います。例えば、製品の一般的なライフサイクルは、設計アイデアとして始まり、プロトタイプになり、生産に入り、そしてある時点で廃止され、もはや製造または販売されなくなるというものです。

設計の各コンポーネントにライフサイクルステータス情報を使用することで、新しい状態が設計内の最低状態コンポーネント以下である場合にのみ、設計をより高い状態に昇格させることができるようになります。例えば、設計が生産に移行する準備ができている場合、それに含まれるすべてのコンポーネントも生産中である場合にのみ、そうすることが許可されるべきです。つまり、まだプロトタイプ中（または設計からの新規）のコンポーネントは、設計全体がそのレベルに昇格する前に生産中に昇格させる必要があります。

多くの場合、設計アイテムのリビジョンは、さまざまなライフサイクル状態を線形に進行しますが、これが唯一の経路であると仮定すべきではありません。例えば、一部のアイテムリビジョンは、プロトタイピング段階に到達する前に放棄されることがあります。接続されたワークスペースでは、アイテムのリビジョンが移動できる許可された状態は、ライフサイクル定義に含まれる遷移表によって定義されます。

接続されたワークスペースは、ライフサイクル管理の2つのレベルをサポートしています：シンプルまたはアドバンスド。これらは基本的に管理のスタイルを決定し、その上でライフサイクル定義自体が構築されます。シンプルな管理スタイルに基づくライフサイクル定義の場合、状態と状態遷移のみが関与します。アドバンスドな管理スタイルに基づくライフサイクル定義の場合、状態はさらに定義された段階にクラスター化されることがあります。

状態、段階、および遷移

関連ページ： 詳細なアイテムビューへのアクセス

アイテムリビジョンのライフサイクルの各ポイントは状態として参照されます。例えば生産中などです。アイテムのリビジョンが状態を変更する場合、それは遷移として参照され、それは他の状態へのものに限られます。

アドバンスドな管理スタイルに基づくライフサイクル定義は、状態を段階にクラスター化することをサポートしています。段階により、アイテムのリビジョンが開発のどの段階にあるかを識別するラベルを作成できます。例えば、それは設計中、またはプロトタイプ中、または生産中である可能性があります。

状態が3つの段階にクラスター化されたライフサイクル定義の例。

下の画像は、3段階のリビジョン命名スキーム（モデル、プロトタイプ、リビジョン）を採用したアイテムの詳細なItemビューのスニペットを示しています。各モデルは別々のブロックとして表示されます。モデル内では、各プロトタイプがサブブロックとなります。各プロトタイプの下には、そのモデル/プロトタイプのリビジョンがあり、リビジョン内にはそのリビジョンが存在したさまざまな状態があります。

アイテムのさまざまなリビジョンに対するライフサイクルの状態の例。

デフォルトライフサイクル定義

接続されたワークスペースは、8つのデフォルトライフサイクル定義を提供します。これらのデフォルト定義はそのまま使用することも、会社や個人の要件に合わせて変更することもできます。また、新しいカスタム定義を追加し、必要に応じて設定することも可能です。

デフォルトのライフサイクル定義は次のとおりです：

• Component Lifecycle
• Design Lifecycle
• Extension Lifecycle
• Generic Lifecycle
• Sample - Basic Lifecycle
• Sample - Simple Lifecycle
• Sample - Simple Lifecycle With Approvals
• Sample - Structured Lifecycle With Approvals

適用されるライフサイクル定義は、アイテムを作成する際に個々のアイテムレベルで選択されます。したがって、異なるアイテムには異なるライフサイクル定義が割り当てられる場合があります。

ライフサイクル定義の管理

Altium Designerの内部から、ライフサイクル定義はEdit Lifecycle Definitionsダイアログ内で表示および管理できます。現在サインインしている接続されたワークスペースのこのダイアログにアクセスするには：

1. PreferencesダイアログのData Management – Serversページを開きます。

2. アクティブサーバーのエントリーの最右端にあるPropertiesコントロールをクリックします。

3. 関連メニューからLifecyclesコマンドを選択してください。

アクティブな接続されたワークスペースのライフサイクル定義は、Altium Designer内のEdit Lifecycle Definitionsダイアログを通じて作成および編集されます。

新しい定義を追加する

新しいライフサイクル定義を作成するには、Edit Lifecycle Definitionsダイアログの下部にあるボタンをクリックします。ダイアログに新しいタブが表示され、設定される準備が整います。

独自のカスタムライフサイクル定義を作成してください。

新しく追加されたライフサイクル定義は、そのタブに'+'のサフィックスが付いていることで区別されます。これは、その定義がまだ設定中であり、ワークスペースで利用可能なライフサイクル定義のセットにまだ「保存」されていないことを反映しています。

定義の設定

ライフサイクル定義のタブ内で利用可能なコントロールを使用して、その定義を必要に応じて構成します。

最初に、Definition Nameフィールドに意味のある名前を入力してください。タブは、入力された名前を動的に反映します。

Lifecycle Managementコントロールを使用して、ライフサイクル管理のスタイルを選択します - SimpleまたはAdvancedのいずれかです。シンプルスタイルは、関与するのが状態と状態遷移だけであることを意味します。アドバンスドスタイルでは、状態がクラスター化されるステージの定義が可能です。

ライフサイクル定義の名前とスタイルを指定してください。

初期状態

アイテムのリビジョンの初期状態を決定するには、Initial State of Revisionsフィールドを使用します。つまり、公開データを含まないリビジョンの状態、いわば「プレリリース状態」です。デフォルトでは、この状態はPlannedと名付けられています。これを変更するには、リンクをクリックし、State Propertiesダイアログを使用してその名前と説明、テキストおよび背景色を決定します。

リビジョンの初期状態を設定します。

ステージ

ライフサイクル管理のAdvancedスタイルが選択された場合、必要なステージを追加して定義するためのコントロールが利用可能になります。デフォルトでは、Design -という名前の単一ステージが提供され、さらに2つのステージを追加することができます。追加のステージを追加するには、Add Stageリンクをクリックします。

必要に応じて、各Stage Nameフィールドに直接入力することでステージの名前を入力してください。

必要に応じてステージを追加し、状態をクラスタリングして、より豊かで構造化されたライフサイクル定義を作成します。

ステージを削除するには、該当するコントロールをクリックします。

状態

次のステップは、ライフサイクル定義に必要な状態を追加することです。管理のシンプルなスタイルに基づくライフサイクル定義の場合、これはフラットリストになります。高度な管理スタイルの場合、定義された各ステージに状態を追加する必要があります。

状態リストの下にあるコントロールをクリックして新しい状態を追加します。表示される状態プロパティダイアログを使用して、その状態を名前、説明、色属性の観点から定義します。

ライフサイクル定義に状態を追加します。

新しい状態はリストの最下部に追加されます。状態を選択してから、およびコントロール（状態リストの下）を使用して、リスト内の必要な位置に移動します。

高度なスタイルのライフサイクル定義の状態を定義する場合、追加のコントロールが利用可能になります（状態リストの下）ステージ間で状態を移動するために。ステージの位置に応じて、右のステージ（）へ、または左（）へ状態を押し出すことが必要です。

状態のプロパティを編集するには、それを選択してから、右端にあるコントロールをクリックします。選択した状態を削除するには、コントロールを使用します。

2段階のライフサイクル定義を通じて定義された例示状態。

遷移

最後のステップは、状態遷移を定義することです – 異なる状態間のパスです。状態を選択するにはクリックし、次に最右のコントロールをクリックして新しい状態遷移を追加します。表示されるState Transition Propertiesダイアログを使用して、名前、対象（次の）状態、メニュー テキスト、および権限の観点から遷移を定義します。

状態遷移を追加します。

新しいトランジションがリストの底に追加されます。トランジションをクリックして選択し、状態リストの下にあるおよびコントロールを使用して、リスト内の必要な位置に移動します。

遷移の次の状態が異なる段階にある場合、ターゲット状態の色で示された矢印が表示され、これを示します。

二段階ライフサイクル定義における完全に定義された状態と状態遷移の例。矢印はステージ間の遷移を示すために使用されます。

シンプルなライフサイクル定義のすべての定義された状態と遷移、または高度なライフサイクル定義の特定の段階のすべての状態と遷移を完全に削除するには、該当する右クリックコンテキストメニューから利用可能なClearコマンドを使用します。

ライフサイクル状態間の遷移を制御する

接続されたワークスペースは、そのワークスペース内のアイテムリビジョンの特定の状態遷移を誰が行うことができるかを決定するための優れた柔軟性を提供します。これは、親アイテムのライフサイクル定義によって定義されたように、リビジョンをある状態から異なる別の状態に遷移させるアクションです。標準（非管理者）ユーザーが特定のライフサイクル状態間での遷移を制限しつつ、ワークスペース管理者だけでなく、より多くの権限を開放することが可能です。グローバルレベルでの権限を指定する能力があります。これはワークスペースのグローバル操作権限の一部として、また個々の状態遷移レベルでも可能です。後者は、グローバルレベルの設定と連携して動作し、より重要な遷移（例えば、アイテムリビジョンをReady for Productionに設定すること）のための権限の微調整を容易にします。

また、標準ユーザーは特定の状態遷移の承認を要求するように設定できます。その結果、これらの承認要求は、一つまたは複数の承認グループのメンバーに指定された人々に送信され、表示され、対応されます。

さまざまなレベルの権限管理により、組織の好ましいアプローチに従ったライフサイクル状態遷移戦略を定義できます。

権限は二つのレベルで定義できます：

• Globally – 定義されたライフサイクル定義全体にわたる、すべての定義された遷移の範囲に対して、どのユーザーおよび/またはグループが状態遷移を実行できるかを定義します。

• Locally – 個々の状態遷移レベルでの権限を指定する。

グローバル状態遷移権限

グローバルな状態遷移権限は、Altium Designer内のEdit Operation Permissionsダイアログを使用して定義および管理されます。このダイアログには、PreferencesダイアログのData Management – Serversページからアクセスできます。権限を参照または変更したい接続されたワークスペースについては、右側のPropertiesコントロールをクリックし、関連するメニューからOperationsコマンドを選択してください。

ここで重要なワークスペース操作のエントリは、Move revision between lifecycle statesです。

ライフサイクル状態の遷移を実行することを許可されている人物を、グローバルレベルでアクセスし構成します。

新しい接続されたワークスペースのために、この操作のデフォルトの権限設定は次のとおりです。

• 管理者

• コラボレータ

• ライブラリ担当者

• マネージャ

必要に応じて追加の権限を定義します（Addボタンをクリックしてください）。このグローバルレベルでの状態遷移権限は、次のエンティティに割り当てることができます：

•   ​ 管理者（それ自体が定義されたグループ）。

•   ​ コラボレータ（これはアイテム/リビジョンの編集権を持つユーザーです）。

•   ​ オーナー（リリースされたデータに関して、これは初期アイテムを作成した人物です）。

•   ​ 特定のユーザー定義グループ。

•   ​ 特定のユーザー

ユーザーおよび定義されたグループの管理は、ワークスペースのブラウザベースのインターフェースを使用して行われます。これは外部ブラウザから行うことができます。詳細情報については、「ワークスペースメンバーシップの管理」（Altium 365 Workspace、Enterprise Server Workspace）を参照してください。

ローカル状態遷移許可

特定の状態遷移に対する権限は、現在、State Transition Propertiesダイアログで構成されているライフサイクル定義の該当するStates and Transitions領域からアクセスされる関連付けられたEdit Lifecycle Definitionsダイアログで定義されています。

トランジションのプロパティを編集するには、それを選択してから、右端にあるコントロールをクリックします。

編集中の状態遷移のための権限を定義するアクセス制御。

State Transition Permissionsフィールドを使用して、トランジションに使用するパーミッション コントロールのタイプを選択します。次の 2 つのオプションが用意されています：

• Controlled – このタイプでは、1人または複数のユーザーおよび/またはグループの指定を通じて、誰がこの遷移を実行できるかを正確に絞り込むことができます。このタイプのローカル権限制御は、グローバルレベルで設定された権限と組み合わせて使用されます（権限の適用方法を参照）。以下の領域のコントロールを使用して、許可されるエンティティを適宜定義してください。デフォルトでは、Anyoneエンティティが追加されており、これはこのローカルレベルですべてのユーザーが遷移を実行することを許可されていることを意味します。

  特定のユーザーやグループを設定するには、まずAnyoneエンティティを選択してから削除します。その後、Addボタンに関連付けられたメニューから必要に応じてユーザーまたはグループを追加できます。Search for UsersやSearch for Roleを使用して、それぞれ必要なユーザーやグループを見つけます。

  
  Controlled権限を使用すると、誰でもアクセスできる状態から指定されたユーザー/グループのみに切り替えることができます。

• Using Approvals – このタイプでは、標準ユーザーがこの状態遷移を実行するようにリクエストできます。リクエストは、定義された承認グループに個別またはグループを通じて追加された1人以上のユーザーによって処理されます。そのようなグループの任意のメンバーが、遷移リクエストを承認または拒否できます。さらに、複数の承認グループを定義して順序付けすることもできます。これにより、複数レベルの承認が可能になります。

  以下のコントロールを使用して、承認グループを適宜定義します。デフォルトでは、空の承認グループが1つ追加され、準備が整います – New Approval Group。これは、Addボタン（または領域の右クリックメニュー）に関連付けられたメニューからEdit Approval Group Nameコマンドを使用して必要に応じて名前を変更できます。

  選択した承認グループに必要に応じてユーザーまたはグループを追加できます。Addボタン（または領域の右クリックメニュー）に関連付けられたメニューから。Search For UsersダイアログやSearch For Roleダイアログを使用して、それぞれ必要なユーザーやグループを見つけます。メニューからMove UpおよびMove Downコマンドを使用して複数の承認グループを順序付けします – 承認は上から下へ行われます。

  
  Using Approvalsでは、非管理ユーザーはすべて遷移をリクエストする必要があり、定義された承認グループのユーザーによって対応されます。

権限の適用方法

権限の適用方法は、状態遷移レベルで選択および設定された権限制御のタイプによって異なります：

• Controlled Permissions – ユーザーが状態遷移を実行できるようにするためには、以下の条件が満たされている必要があります：

  • グローバルレベルでMove revision between lifecycle states（Edit Operation Permissionsダイアログで定義）の権限を持っている必要があります。

  • この特定の状態遷移に対してローカルレベルで権限を持っている必要があります。

  • アイテムリビジョンのライフサイクル状態が遷移されている場合、コラボレーターである必要があります（つまり、編集権を持っている必要があります）。

  これら3つの条件はAND条件です – 1つでも満たされていない場合、その特定の遷移を実行することはできません。
  非管理ユーザーの場合、デフォルトの権限設定（グローバルレベルでのCollaborator、およびローカル状態遷移レベルでのAnyone）は、必要なアイテムリビジョンのコラボレーターにユーザーをするだけで、すべての条件を満たすことを意味します。その後、重要な遷移については、ローカル状態遷移レベルで権限を厳しくすることで、どのコラボレーターでも遷移を実行できないようにすることができます。

• Using Approvals – すべての非管理ユーザーは承認システムを使用して状態遷移を実行するリクエストを送信する必要があります。承認システムでは、ユーザーがグローバルレベルで状態遷移を行う権限を持っている必要はなく、アイテムリビジョンのコラボレーターである必要もありません。

  ユーザーがアイテムリビジョンのコラボレーターである必要はありませんが、それが共有されていない場合、ワークスペースでそれを見ることはできません。

段階とリビジョン命名スキームのレベルを関連付ける

リビジョンとライフサイクルの状態は、Itemビューの適用される右クリックメニューまたはExplorerパネルのLifecycleアスペクトビュータブからインクリメントできます。新しいリビジョンを確立し、ライフサイクルを昇進させることは、異なる理由で行われる完全に別の作業であり（設計変更がある場合には新しいリビジョンが、新しいライフサイクル状態はそのアイテムリビジョンの使いやすさの向上を反映します）、相互に関連しています。

高度な管理スタイルに基づくライフサイクル定義では、定義された段階は、使用されているリビジョン命名スキームのリビジョンレベルにリンクできます。これをEdit Lifecycle Definitionsダイアログの下部にあるオプションを使用して行ってください。

ステージをリビジョンレベルにリンクするオプション。

これによりライフサイクルステージとリビジョンレベルとの関係が生まれます。つまり、アイテムリビジョンのライフサイクルがインクリメントされて、あるステージの状態から別のステージの状態に移動する際、右クリックメニューにある利用可能なリビジョン変更タイプコマンドも変わるということです。

デフォルトのライフサイクル定義Sample - Structured Lifecycle With Approvalsと、3レベルのリビジョン名付けスキーム（リビジョン、プロトタイプ、モデルのレベル）。アイテムリビジョンがNew From Design状態にある場合、最初の段階では、右クリックメニューのリビジョンタイプのオプションには、新しいリビジョンの設定、新しいプロトタイプ、および新しいモデルが含まれます。

ライフサイクルがインクリメントされてIn Prototypeの段階に達した場合、第二段階に移行します。それを右クリックすると、利用可能なリビジョンタイプのオプションには新しいプロトタイプを確立するか、新しいモデルが含まれています。つまり、新しいリビジョンを開始するオプションはありません。この動作は直感的に期待されるもので、デザインがプロトタイプに進展した場合、デザイン変更が必要なら、新しいプロトタイプが必要になりますし、その変更の範囲によっては新しいモデルが必要になることもあります。

アイテムリビジョンがIn Productionの状態に達すると、第三段階では新しいモデルを確立するためのリビジョンタイプのオプションが再び期待通りにのみ利用可能になります。

リンクされた場合、リビジョンタイプのコマンドは、アイテムリビジョンのライフサイクル状態が定義されたさまざまな段階を進むにつれて変更されます。

定義を保存する

新しいライフサイクル定義が追加された場合、または既存のライフサイクル定義が何らかの形で変更された場合、そのライフサイクル定義は保存されなければなりません。実際の「保存」コントロールは存在しませんが、これを実行するためのコントロールは用意されています：

• 新しいライフサイクル定義には、「+」のサフィックスが付いており、定義のタブの右上にあるAdd Definitionコントロールを使用するか、ダイアログのメイン   ボタンをクリックします。

• 変更が加えられた既存のライフサイクル定義（'*'のサフィックスで区別される）については、定義のタブの右上にあるApply Changesコントロールを使用するか、ダイアログのメイン   ボタンをクリックしてください。

いずれにせよ、接尾辞は削除され、新しい（または変更された）定義がワークスペースで利用可能なライフサイクル定義のセットの一部として利用できるようになります。

明確で透明な監査トレイルを促進する精神で、誰が何を、いつ変更したかの詳細が、ライフサイクル定義が最後に変更された日時として、タブの右下に提供されています。

ライフサイクル定義が最後に変更された時期と、誰によって変更されたかを特定すること。

定義の改名

既存の使用中のライフサイクル定義を再命名するには：

1. アクティブな接続されたワークスペースのEdit Lifecycle Definitionsダイアログにアクセスします。

2. 名前を変更する必要がある定義のタブをクリックしてください。

3. Definition Nameフィールドの名前を変更します。

ライフサイクル定義の名称変更の例と、その定義をすでに使用しているアイテムのプロパティの変更を検証すること。

定義のコピー

新しいライフサイクル定義を一から作成する必要はありません。ライフサイクル定義の編集ダイアログでは、既存の定義をすばやくコピーすることができます。そのためには：

1. コピーする必要があるライフサイクル定義をアクティブな定義として設定します。

2. その定義のタブの右上にあるMake a copyコントロールをクリックします。

3. 定義の正確なコピーが作成され、初期のデフォルト名New Lifecycle Definitionで新しい定義が作成されます。必要に応じて名前を変更してください。

4. 新しい定義を実際に保存するために、Add Definitionコントロール（またはメインのボタン）をクリックします。

定義の削除

既存のライフサイクル定義を削除するには、それを選択してEdit Lifecycle Definitionsダイアログでアクティブな定義にし、その定義のタブの右上にあるDeleteコントロールをクリックします。

ライフサイクル定義の永久削除は、ダイアログのメインボタン（またはOKをクリック）をクリックすることで行われます。これに先立ち、削除操作はダイアログの下部にあるボタンをクリックすることで元に戻すことができます。

ライフサイクル定義の削除操作は元に戻すことができます。

定義のエクスポートとインポート

ユーザー定義のライフサイクル定義は、それらが定義されている接続されたワークスペースでのみ使用できます。ライフサイクル定義の編集ダイアログには、定義をワークスペース間で移植するためのエクスポートとインポートの機能があります。

ライフサイクル定義をエクスポートするには、そのタブの右上にあるExportコントロールをクリックします。続くライフサイクル定義の保存ダイアログを使用して、ファイルをどこに、どの名前で保存するかを決定します。

ライフサイクル定義をインポートするには、ボタンをクリックしてライフサイクル定義の編集ダイアログの下部にあります。必要なライフサイクル定義ファイルを参照して開くためにライフサイクル定義を開くダイアログを使用します。ライフサイクル定義は、ワークスペースで利用可能な既存のライフサイクル定義のリストに追加されます。

ライフサイクル定義の使用制御

特定のアイテムタイプが使用できる特定のライフサイクル定義については、各定義を定義する際にグローバルレベルで定義および有効化することにより制御できます。この機能が有効になっている場合、特定のアイテムタイプのライフサイクル定義を選択するときに、許可された定義のみが利用可能になります。これにより、特定のタイプの作成されたアイテムが必要とするライフサイクル定義のみを使用するという追加の制御レベルを得ることができます。

制御はContent Typesダイアログ内で行われます。アクセスを構成したい特定の定義のタブをクリックし、次に定義のタブの右上にあるContent Typesリンクをクリックします。

Content Typesダイアログへのアクセス – どのコンテンツタイプが構成されているライフサイクル定義を使用できるかを決定するためのコマンドセンター。

Content Typesダイアログは、アクティブな接続されたワークスペースで作成できる（ユーザーによって、またはシステムによって）すべてのサポートされているコンテンツタイプをリストします。リストの上にあるオプション – Control Lifecycle Definition per Content Type – は、その特定の定義に対してこの機能がアクティブ（有効）かどうか（無効）をグローバルに制御するためのものです。このオプションを有効にし、その定義を使用したい各コンテンツタイプの関連するUseオプションを有効にします。

高度なライフサイクル管理モードとシンプルなライフサイクル管理モードの切り替え

既存のライフサイクル定義をAdvancedライフサイクル管理スタイル（状態、状態遷移、ステージ）からSimple管理スタイル（状態と状態遷移のみ）に切り替えることができます。Simpleオプションを有効にすると、Confirm Merge Statesダイアログが表示されます。このダイアログを使用して、切り替えを次のように処理する方法を決定します。

• Yesをクリック – ステージ1、2、3全体にわたるすべての定義された状態（および状態遷移）が、1つのフラットな状態リストに統合されます。

• Noをクリック – ステージ2と3で定義されたすべての状態（および状態遷移）が削除されます。ステージ1（最も左のステージ）の状態（および状態遷移）のみが、単一のフラットな状態リストに残ります。

ライフサイクル管理のスタイルを、他のステージでの状態（および状態遷移）の扱いを制御しながら、AdvancedからSimpleに切り替えます。

状態遷移承認要求

次のセクションでは、承認システムを使用して、ワークスペースの非管理者ユーザーが特定の状態遷移を実行できるようにするさまざまな側面について詳しく見ていきます。

リクエストの作成（承認のリクエスト）

Altium Designer内での状態遷移の承認要求は、必要なアイテムリビジョンのLifecycleアスペクトビュー（Explorerパネル内）または詳細Itemビューのグラフィカルライフサイクル領域から実行されます。リビジョンのライフサイクルを右クリックし、遷移を要求するコマンドを選択します。Confirmダイアログが表示され、要求を行う理由としてメモを入力できます。これにより、承認グループのメンバーがあなたの要求を承認するかどうかの検討に役立ちます！要求の作成を実行するにはYesをクリックします。

状態遷移を要求し、あなたのケースを裏付けるために役立つメモを追加してください。

作成時に、その状態遷移に適用される承認グループのメンバーは、メール通知機能が有効になっている場合、メール通知を受け取ります。

承認リクエストの表示

状態遷移要求の発信者（リクエスター）と、その状態遷移の適用承認グループで定義されたユーザー（アプローバー）の両方に対して、保留中の要求は専用のApproval Requestsフォルダを使用してExplorerパネルを通じて提示されます。

Approval Requestsフォルダ内の承認リクエストの例で、リクエスタ（サイモン・エンティスト）と特定の状態遷移のための定義された（初期）承認グループのメンバーの一人（デス・アイグナー）が閲覧したものです。

Approval Requestsフォルダ名の横にある数字は、保留中のリクエストの数を示しています。Show Approved Requestsを表示するオプションが有効になっている場合（メニューから）、この数字は合計（保留中 + 承認済み）を反映します。

各承認要求について以下の情報が提示されます：

• Item Revision – リクエストが行われている特定のアイテムのリビジョン。

• Requested By – リクエストの発信者（リクエスター）。ここに入力するのはユーザーのユーザー名です。

• Requested At – リクエストが作成された日時。

• Status – リクエストの現在の状態。これは以下のいずれかの状態である可能性があります：

  • Awaiting – リクエストは現在、1人以上の承認者によるアクションを待っています。

  • Approved – リクエストは承認されました。この状態は、その遷移のために定義されたすべての承認グループからの完全な承認が得られた場合のみ入ります。

• Transition – このアイテムのリビジョンに対して要求されている特定の状態遷移。

• Request Note – リクエスターによってリクエストが行われた際に追加されたメモ。

• Action Forward – ここに示されているコントロールは、保留中のリクエスト（状態がAwaitingのもの）のみのものであり、コントロールは次のように2つの当事者に合わせて異なります。

  • リクエスター – リクエストを作成したユーザーは思い出すことができます。

  • 承認者 – 承認グループ内のユーザーは、リクエストを承認できます。

• Action Backward – ここに示されているコントロールは、保留中のリクエスト（状態がAwaitingのもの）のみのものであり、コントロールは次のように2つの当事者に合わせて異なります。

  • リクエスター - リクエストを作成したユーザーは、それをCancelできます。

  • 承認者 - 承認グループ内のユーザーは、リクエストをRejectできます。

リクエストの処理

前のセクションで簡単に説明したように、リクエスターと承認者はそれぞれが取れるアクションがあります。以下の折りたたみセクションでは、それぞれのアクションをより詳しく見ていきます：

承認情報ストリーム

リクエストが承認されると、その承認リクエストを閲覧する際に、ページの中央領域にも通知が利用可能になります。この情報には、以下の要素が含まれます：

• Created At - 承認リクエストが承認された日時。

• Created By - リクエストを承認した関連承認グループのメンバー。ここに入力するのはユーザー名です。

• Description – 承認が行われた時に承認者によって含まれたメモと共に、自動生成メッセージからなるエントリ。説明の自動生成部分は、承認の種類に依存します：

  • 最終承認（唯一の、または最後の承認グループのメンバーから） – task approved and completed.

  • 中間承認（最終承認グループではない承認グループのメンバーからの） – task approved and assigned to next approval group <ApprovalGroupName>.

   

特定のアイテムリビジョンに対する承認フローの例で、リクエスターが見たものです。この場合、承認は二つの異なる承認グループのメンバーから承認を得るという二段階の承認を通過する必要がありました。

次の人々がこの情報を見ています：

• 状態遷移のリクエスター。

• リクエストの最終承認を行うユーザーです。したがって、複数の承認グループが関与している場合、最終承認を行う最終承認グループのメンバーのみがこの情報を見ることができます。一時的な承認を行う承認グループのメンバーは、この情報を表示することはできません。

アイテムリビジョンの可視性と適用性の制御

ライフサイクル定義のために各個別の状態を設定する際には、そのライフサイクル定義を使用し、その状態に入るアイテムのリビジョンの可視性や適用性を制御する追加の状態属性を定義する能力があります。適用性の観点から、プロジェクト違反レポートも構成され、適用外の状態にあるリビジョンを持つデザインで使用されているワークスペースアイテムを検出してフラグを立てることができます。これにより、リリース前に問題を把握し回避することができます。

特定の状態におけるアイテムのリビジョンが表示可能かつ適用可能であるかを判断するためのコントロールは、State Propertiesダイアログにあります。Edit Lifecycle Definitionsダイアログの中から必要な状態のために、このダイアログにアクセスするには、親ライフサイクル定義内の状態のエントリをダブルクリックするか、そのエントリを選択して表示される編集アイコン ()をクリックします。

その状態に入るアイテムリビジョンの可視性および/または適用性を制御するために、状態レベルで定義された属性を使用します。

二つの選択肢は次の通りです：

• Visible in Vault panels – このオプションが有効になっている場合、親ライフサイクル定義を使用したアイテムの改訂が、このライフサイクル状態に設定されると、Explorerパネルに表示されます。このオプションが無効になっている場合、改訂は非表示になります。非表示の改訂は、エクスプローラーパネル内でShow Hidden Revisionsコントロールを有効にすることで表示できます（非表示の改訂の表示を参照）。

• Allowed to be used in designs – このオプションが有効である場合、この状態のアイテムリビジョンはデザインで使用することが許可されます。これは適用可能と見なされます。このオプションが無効の場合、この状態のアイテムリビジョンは有効に使用することができず、適用外（または非適用）と見なされます。その場合、プロパティパネルやItem Managerダイアログにフラグが付けられます（適用外リビジョンのフラグ付けを参照）。プロジェクトコンパイラも、このような事象を検出するように構成できます（コンパイル時の適用外リビジョン状態の検出を参照）。

隠された改訂を表示

ライフサイクル状態に入るアイテム修正がVisible in Vault panels属性が無効になっている場合、その修正はデフォルトでExplorerパネルに表示されません。そして、それがアイテムの最新修正である場合、そのアイテムの全エントリは事実上表示されなくなります。この可視性状態は、状態レベルで定義されており、Explorerパネルでブラウズする際にすべてのアイテムに対してグローバルにオーバーライドできます。現在表示されていないすべてのアイテム修正を表示するには、パネルのItems領域の右上にあるコントロールをクリックし、関連するメニューでShow Hidden Revisionsオプションを有効にしてください。

Explorerパネルでコンテンツを閲覧しているときに、隠されたアイテムの修正を表示します。画像にカーソルを合わせると結果が表示されます。

不適用な改訂のフラグ

通常、非表示に設定されたライフサイクル状態（Visible in Vault panelオプションが無効）は、適用不可にもなります（Allowed to be used in designsオプションも無効）。たとえば、現在ObsoleteまたはDepracatedとされているコンポーネントの改訂版は、最新のデザインスピンには存在すべきではありません！このような状態に入ったアイテムの改訂版を隠すことは一つのことですが、たとえばコンポーネントが見えない場合、配置することはできません。しかし、デザイン内でそのようなアイテムの改訂版のインスタンスを既に使用しているか、隠された改訂版を表示しているために、適用不可の改訂版をうっかり配置してしまうことがあるかもしれません！

心配しないでください。コンパイレーション時に不適用状態のコンポーネントアイテムリビジョンをキャッチすることを除けば（次のセクションを参照）、デザインソフトウェア内でアイテムリビジョン（コンポーネントと管理シート）の適用性を手動で確認できます。これは、アイテムのプロパティをブラウジングする際のPropertiesパネル、またはアイテムマネージャーを使用することで実現されます。

• Properties panel – このパネルを使用してコンポーネントまたは管理された回路図シートのリビジョンの配置インスタンスのプロパティをブラウズする際、リビジョンステータスエントリの右側に表示が出ます。リビジョンが適用不可の状態（設計で使用することが許可されていない）である場合、エントリにはNot applicableと表示されます。リビジョンが適用可能な状態（設計で使用することが許可されている）である場合、エントリにはそのリビジョンが最新であること（Up to date）またはそうでないこと（Out of date）を反映します。

  

  コンポーネントの修正の配置されたインスタンスに対するプロパティレベルでの不適用性を反映し、管理された回路図シート。

• Item Manager – Item Managerダイアログ（Tools » Item Manager）では、Revision Statusフィールドに表示される情報が示されます。リビジョンが不適用状態（設計に使用することが許可されていない）である場合、エントリにはNot applicableと表示されます。リビジョンが適用状態（設計に使用することが許可されている）である場合、エントリはそのリビジョンが最新であること（Up to date）またはそうでないこと（Out of date）を反映します。

  
  コンポーネントの改訂版の配置インスタンスと管理された回路図シートに対するItem Manageダイアログを通じて、適用不可能性を反映しています。

プロジェクト検証における適用不可能な改訂状態の検出

コンポーネントアイテムリビジョンの設置されたインスタンスについて、これらのリビジョンの状態の適用性は、プロジェクト検証の一環として確認できます。この確認の核心は、コンポーネントリビジョンが不適用状態違反タイプを持つことであり、これはコンポーネントに関連する違反のカテゴリの一部です。このチェックの報告モードをProject OptionsダイアログのError Reportingタブで設定します。

プロジェクトの検証には、適用できない改訂状態にあるコンポーネントに関する違反のチェックが含まれます。配置されたコンポーネントアイテムの改訂のライフサイクル状態が設計目的で許可されていないと指定されている場合、違反が発生します。

コンパイラエラーと警告が回路図に表示するように設定されている場合（設定はPreferencesダイアログのchematic – Compilerページで行います）、問題のあるオブジェクトの下には色付きの波線が表示されます。また、通知はMessagesパネルに以下の形式で表示されます：

Component <Designator> <Comment>: Component revision has inapplicable state,

where:

• Designator はコンポーネントインスタンスの指定子です。

• Comment はコンポーネントインスタンスのコメントです。

例外違反（影響のため致命的エラーに設定）

注意すべき事項：

• 配置されたコンポーネントが、配置された接続ワークスペースとの接続を失うと、例えばそのワークスペースが切断された場合や、ワークスペースからサインアウトされた場合、Component revision has inapplicable stateチェックに違反します。これはメッセージパネルに反映され、次の形式のエントリが表示されます:Component <Designator> <Comment>: Can't perform revision status validation: Failed to connect to server。

• 設計リリースプロセス中に設計内で不適切に使用されているコンポーネントをキャッチすることもできます。全体のリリース検証体制にコンポーネント状態チェックを追加して構成してください。詳細については、コンポーネントステータスの検証を参照してください。