PHENOM Portal Knowledgebase - User contributions [en]

CSV

2025-12-15T20:49:22Z

Josh: Update to the CSV import page after refactor

The CSV import tool allows users to bulk import data into their model, both creating new nodes and editing existing nodes.

[[File:Csv before import.png|frameless|1199x1199px]]

Simply select a CSV file to import which is less than 5MB, and press the import button. Depending on the size of the file, it may take some time to process.

When the processing is finished, an error message will appear if the columns in the CSV file do not fit any of the acceptable formats. If the imported CSV file is valid, a table will appear for review displaying all of the created and edited nodes, as well as a summary of the import.

[[File:Csv after import.png|frameless|1190x1190px]]

Visible in the list is the following information about the processed node:

* Row Number (corresponding to the CSV line number in which the node was created or edited)
* Node Name
* Node Validity
* Node Type
* Node Guid (If this would be a new node, the guid would be replaced with "New")

There are many actions to take on this table, including:

* Nodes may be manually selected or unselected to be saved using the check box in the far left of the row. All rows are selected by default.
* Select a node to see and potentially edit its attributes. If the node is not valid, the node must be edited before finishing the import.
* Reset any manual edits made to the node using the far right column in the row.

To save the changes displayed to the model, press the "FINISH IMPORT" button. Navigating away before pressing this button will not save any of the processed nodes.

== CSV Header Formats ==
Valid formats a user can import are:
* Views & View Characteristics (see [[Formatting a CSV for View Import]])
* Enumerations (see [[Formatting a CSV for Enum Import]])
* Entities & Associations (see [[Formatting a CSV for Entities and Associations Import]])
* Constraints
* Platform Types
* UoPs

File:Csv after import.png

2025-12-15T20:47:12Z

Josh:

CSV import page after the import has begun, where the user may review the processed nodes

File:Csv before import.png

2025-12-15T20:25:59Z

Josh:

CSV import page before the file has been processed

User Settings

2025-12-15T20:16:42Z

Josh: /* Manage Users */

The account and user settings pages are where the user can go to view profile specific information.

You can access the account and user settings by clicking on icon in the upper-right of PHENOM.

[[File:Phenom settings 1.png|border]]

From this menu item, you can access additional user settings or logout.

== Account ==

=== General Information ===
This page contains information about your personal PHENOM user under the "ACCOUNT" tab, including username, email address, and phone number. This page also allows you to change your password and set up two-factor authentication.

[[File:Account general info 2.png|border|frameless|395x395px]]

== Subscription Management ==
These pages are only available to account administrators, and is accessible under the "SUBSCRIPTION" tab. Account admins can use this tab to:

* create, edit, and delete users
* assign, revoke, and reassign PHENOM licenses
* manage permissions of all projects and models associated with the account

=== Manage Users ===
Under the "USERS" tab, an account admin is able to see all users associated with their PHENOM account, as well as information about the account's licenses

==== '''Creating Users''' ====
[[File:New user button.png|frameless]]

The icon to create a user is in the top left of the page, and will open a form into which the new user's details can be entered.

[[File:New user form.png|alt=PHENOM new user form|frameless|939x939px]]

Every user needs to have a working Project, so you can select the Project which the new user will be loaded into initially.

* Selecting the option "Create personal copy with Admin permissions" will create a copy of the selected Project and make the new user an Admin of the new Project.
** When this option is selected, user creation may take additional time to process in the background.
* Selecting the alternative option, "Share with X permissions", will grant permissions to the selected Project directly at the level which is selected in the drop-down.

Press the save button to create the new user, or the X to cancel creation.

==== Editing Users ====
All existing users that belong to your account will appear on the Subscription page.

[[File:Subscription users page.png|frameless|1245x1245px]]

Account administrators have the option to edit any users':

* email address
* assigned PHENOM license (the expiration date of the assigned license is also shown here. Red indicates expired; yellow indicates expiry within two weeks)
* password
* assigned projects

There are also options to entirely disable or enable users, as well as to grant or revoke account administrator status. Editing any of these fields will highlight the row blue. Click the save button to make the changes go into effect.

Opening up a user's projects will open a page which lists all projects and models to which the user has at least Read permissions to.

==== Deleting Users ====
Click the trash can icon on the far right for the user to delete. Deleting a user will not delete any models that the user had access to, nor the license which the user was using. The license will be freed up to be assigned to any other user.

=== Manage PHENOM Licenses ===
Under the "PHENOM LICENSES" tab, all PHENOM licenses belonging to the account will be listed, alongside the expiration date and the user which is in current use of the license.

[[File:Phenom licenses page.png|frameless|1235x1235px]]

Account administrators are able to assign licenses by selecting from the drop-down and revoke licenses by clicking the un-link icon on this page. After making any changes, press the save button to make the changes go into effect.

On the users page there are also options to revoke, assign, and reassign licenses in the list of users in the same way.

=== Manage CinC Licenses ===
Under the "CINC LICENSES" tab, all CinC licenses belonging to the account will be listed, alongside the license type (either PROD or EVAL), the last Main Program generated, as well as an option to see all logged CinC generations that were produced using that license.

== Settings ==

=== Hide Deprecated Content Option ===
When the "Hide Deprecated Content" option is enabled, all nodes in the loaded in Project will be filtered out from all operations across all of PHENOM. More specifically, deprecated nodes will no longer appear in:

* The Navigation Tree
* Model Generation
* Health Checks
* Many Details pages

It is important to note that enabling this option may hide deprecated nodes that are still being referenced by other nodes.

== Logout ==
This will log the current user out of the current PHENOM Portal session. You will have to login once more to resume working.

User Settings

2025-12-15T20:15:24Z

Josh: Fix broken image links

The account and user settings pages are where the user can go to view profile specific information.

You can access the account and user settings by clicking on icon in the upper-right of PHENOM.

[[File:Phenom settings 1.png|border]]

From this menu item, you can access additional user settings or logout.

== Account ==

=== General Information ===
This page contains information about your personal PHENOM user under the "ACCOUNT" tab, including username, email address, and phone number. This page also allows you to change your password and set up two-factor authentication.

[[File:Account general info 2.png|border|frameless|395x395px]]

== Subscription Management ==
These pages are only available to account administrators, and is accessible under the "SUBSCRIPTION" tab. Account admins can use this tab to:

* create, edit, and delete users
* assign, revoke, and reassign PHENOM licenses
* manage permissions of all projects and models associated with the account

=== Manage Users ===
Under the "USERS" tab, an account admin is able to see all users associated with their PHENOM account, as well as information about the account's licenses

'''Creating Users'''

[[File:New user button.png|frameless]]

The icon to create a user is in the top left of the page, and will open a form into which the new user's details can be entered.

[[File:New user form.png|alt=PHENOM new user form|frameless|939x939px]]

Every user needs to have a working Project, so you can select the Project which the new user will be loaded into initially.

* Selecting the option "Create personal copy with Admin permissions" will create a copy of the selected Project and make the new user an Admin of the new Project.
** When this option is selected, user creation may take additional time to process in the background.
* Selecting the alternative option, "Share with X permissions", will grant permissions to the selected Project directly at the level which is selected in the drop-down.

Press the save button to create the new user, or the X to cancel creation.

==== Editing Users ====
All existing users that belong to your account will appear on the Subscription page.

[[File:Subscription users page.png|frameless|1245x1245px]]

Account administrators have the option to edit any users':

* email address
* assigned PHENOM license (the expiration date of the assigned license is also shown here. Red indicates expired; yellow indicates expiry within two weeks)
* password
* assigned projects

There are also options to entirely disable or enable users, as well as to grant or revoke account administrator status. Editing any of these fields will highlight the row blue. Click the save button to make the changes go into effect.

Opening up a user's projects will open a page which lists all projects and models to which the user has at least Read permissions to.

==== Deleting Users ====
Click the trash can icon on the far right for the user to delete. Deleting a user will not delete any models that the user had access to, nor the license which the user was using. The license will be freed up to be assigned to any other user.

=== Manage PHENOM Licenses ===
Under the "PHENOM LICENSES" tab, all PHENOM licenses belonging to the account will be listed, alongside the expiration date and the user which is in current use of the license.

[[File:Phenom licenses page.png|frameless|1235x1235px]]

Account administrators are able to assign licenses by selecting from the drop-down and revoke licenses by clicking the un-link icon on this page. After making any changes, press the save button to make the changes go into effect.

On the users page there are also options to revoke, assign, and reassign licenses in the list of users in the same way.

=== Manage CinC Licenses ===
Under the "CINC LICENSES" tab, all CinC licenses belonging to the account will be listed, alongside the license type (either PROD or EVAL), the last Main Program generated, as well as an option to see all logged CinC generations that were produced using that license.

== Settings ==

=== Hide Deprecated Content Option ===
When the "Hide Deprecated Content" option is enabled, all nodes in the loaded in Project will be filtered out from all operations across all of PHENOM. More specifically, deprecated nodes will no longer appear in:

* The Navigation Tree
* Model Generation
* Health Checks
* Many Details pages

It is important to note that enabling this option may hide deprecated nodes that are still being referenced by other nodes.

== Logout ==
This will log the current user out of the current PHENOM Portal session. You will have to login once more to resume working.

User Settings

2025-12-15T20:11:46Z

Josh: Remove text wrap from image

The account and user settings pages are where the user can go to view profile specific information.

You can access the account and user settings by clicking on icon in the upper-right of PHENOM.

[[File:Phenom settings 1.png|border]]

From this menu item, you can access additional user settings or logout.

== Account ==

=== General Information ===
This page contains information about your personal PHENOM user under the "ACCOUNT" tab, including username, email address, and phone number. This page also allows you to change your password and set up two-factor authentication.
[[index.php?title=File:Account_general_info_2.png|link=File:Account_general_info_2.png|alt=General information about a user on the PHENOM Account page|border|frameless|552x552px]]

== Subscription Management ==
These pages are only available to account administrators, and is accessible under the "SUBSCRIPTION" tab. Account admins can use this tab to:

* create, edit, and delete users
* assign, revoke, and reassign PHENOM licenses
* manage permissions of all projects and models associated with the account

=== Manage Users ===
Under the "USERS" tab, an account admin is able to see all users associated with their PHENOM account, as well as information about the account's licenses

'''Creating Users'''
[[Index.php?title=File:New user button.png|link=File:New_user_button.png|alt=|frameless]]
The icon to create a user is in the top left of the page, and will open a form into which the new user's details can be entered.

[[File:New user form.png|alt=PHENOM new user form|frameless|939x939px]]

Every user needs to have a working Project, so you can select the Project which the new user will be loaded into initially.

* Selecting the option "Create personal copy with Admin permissions" will create a copy of the selected Project and make the new user an Admin of the new Project.
** When this option is selected, user creation may take additional time to process in the background.
* Selecting the alternative option, "Share with X permissions", will grant permissions to the selected Project directly at the level which is selected in the drop-down.

Press the save button to create the new user, or the X to cancel creation.

==== Editing Users ====
All existing users that belong to your account will appear on the Subscription page.

[[File:Subscription users page.png|frameless|1245x1245px]]

Account administrators have the option to edit any users':

* email address
* assigned PHENOM license (the expiration date of the assigned license is also shown here. Red indicates expired; yellow indicates expiry within two weeks)
* password
* assigned projects

There are also options to entirely disable or enable users, as well as to grant or revoke account administrator status. Editing any of these fields will highlight the row blue. Click the save button to make the changes go into effect.

Opening up a user's projects will open a page which lists all projects and models to which the user has at least Read permissions to.

==== Deleting Users ====
Click the trash can icon on the far right for the user to delete. Deleting a user will not delete any models that the user had access to, nor the license which the user was using. The license will be freed up to be assigned to any other user.

=== Manage PHENOM Licenses ===
Under the "PHENOM LICENSES" tab, all PHENOM licenses belonging to the account will be listed, alongside the expiration date and the user which is in current use of the license.

[[File:Phenom licenses page.png|frameless|1235x1235px]]

Account administrators are able to assign licenses by selecting from the drop-down and revoke licenses by clicking the un-link icon on this page. After making any changes, press the save button to make the changes go into effect.

On the users page there are also options to revoke, assign, and reassign licenses in the list of users in the same way.

=== Manage CinC Licenses ===
Under the "CINC LICENSES" tab, all CinC licenses belonging to the account will be listed, alongside the license type (either PROD or EVAL), the last Main Program generated, as well as an option to see all logged CinC generations that were produced using that license.

== Settings ==

=== Hide Deprecated Content Option ===
When the "Hide Deprecated Content" option is enabled, all nodes in the loaded in Project will be filtered out from all operations across all of PHENOM. More specifically, deprecated nodes will no longer appear in:

* The Navigation Tree
* Model Generation
* Health Checks
* Many Details pages

It is important to note that enabling this option may hide deprecated nodes that are still being referenced by other nodes.

== Logout ==
This will log the current user out of the current PHENOM Portal session. You will have to login once more to resume working.

User Settings

2025-12-15T20:09:55Z

Josh: Updated screenshots and descriptions of settings and account management

The account and user settings pages are where the user can go to view profile specific information.

You can access the account and user settings by clicking on icon in the upper-right of PHENOM.

[[File:Phenom settings 1.png|border]]

From this menu item, you can access additional user settings or logout.

== Account ==

=== General Information ===
This page contains information about your personal PHENOM user under the "ACCOUNT" tab, including username, email address, and phone number. This page also allows you to change your password and set up two-factor authentication.
[[File:Account general info 2.png|alt=General information about a user on the PHENOM Account page|frameless|552x552px]]

== Subscription Management ==
These pages are only available to account administrators, and is accessible under the "SUBSCRIPTION" tab. Account admins can use this tab to:

* create, edit, and delete users
* assign, revoke, and reassign PHENOM licenses
* manage permissions of all projects and models associated with the account

=== Manage Users ===
Under the "USERS" tab, an account admin is able to see all users associated with their PHENOM account, as well as information about the account's licenses

'''Creating Users'''
[[index.php?title=File:New_user_button.png|link=File:New_user_button.png|alt=|frameless]]
The icon to create a user is in the top left of the page, and will open a form into which the new user's details can be entered.

[[File:New user form.png|alt=PHENOM new user form|frameless|939x939px]]

Every user needs to have a working Project, so you can select the Project which the new user will be loaded into initially.

* Selecting the option "Create personal copy with Admin permissions" will create a copy of the selected Project and make the new user an Admin of the new Project.
** When this option is selected, user creation may take additional time to process in the background.
* Selecting the alternative option, "Share with X permissions", will grant permissions to the selected Project directly at the level which is selected in the drop-down.

Press the save button to create the new user, or the X to cancel creation.

==== Editing Users ====
All existing users that belong to your account will appear on the Subscription page.

[[File:Subscription users page.png|frameless|1245x1245px]]

Account administrators have the option to edit any users':

* email address
* assigned PHENOM license (the expiration date of the assigned license is also shown here. Red indicates expired; yellow indicates expiry within two weeks)
* password
* assigned projects

There are also options to entirely disable or enable users, as well as to grant or revoke account administrator status. Editing any of these fields will highlight the row blue. Click the save button to make the changes go into effect.

Opening up a user's projects will open a page which lists all projects and models to which the user has at least Read permissions to.

==== Deleting Users ====
Click the trash can icon on the far right for the user to delete. Deleting a user will not delete any models that the user had access to, nor the license which the user was using. The license will be freed up to be assigned to any other user.

=== Manage PHENOM Licenses ===
Under the "PHENOM LICENSES" tab, all PHENOM licenses belonging to the account will be listed, alongside the expiration date and the user which is in current use of the license.

[[File:Phenom licenses page.png|frameless|1235x1235px]]

Account administrators are able to assign licenses by selecting from the drop-down and revoke licenses by clicking the un-link icon on this page. After making any changes, press the save button to make the changes go into effect.

On the users page there are also options to revoke, assign, and reassign licenses in the list of users in the same way.

=== Manage CinC Licenses ===
Under the "CINC LICENSES" tab, all CinC licenses belonging to the account will be listed, alongside the license type (either PROD or EVAL), the last Main Program generated, as well as an option to see all logged CinC generations that were produced using that license.

== Settings ==

=== Hide Deprecated Content Option ===
When the "Hide Deprecated Content" option is enabled, all nodes in the loaded in Project will be filtered out from all operations across all of PHENOM. More specifically, deprecated nodes will no longer appear in:

* The Navigation Tree
* Model Generation
* Health Checks
* Many Details pages

It is important to note that enabling this option may hide deprecated nodes that are still being referenced by other nodes.

== Logout ==
This will log the current user out of the current PHENOM Portal session. You will have to login once more to resume working.

File:Phenom licenses page.png

2025-12-15T20:03:34Z

Josh:

PHENOM licenses page

File:Subscription users page.png

2025-12-15T19:50:08Z

Josh:

PHENOM subscription users page

File:New user form.png

2025-12-15T19:22:55Z

Josh:

PHENOM new user form

File:Account general info 2.png

2025-12-15T19:07:09Z

Josh:

General information about a user on the account page

File:Account general info.png

2025-12-15T19:02:19Z

Josh:

The general information about a user found on the account page

Review Project

2025-05-13T18:43:26Z

Josh: /* Finalize Merge */

== Review Projects 101 ==
A '''Review Project''' in PHENOM is a temporary workspace created to show the user the outcome of a [[Push,_Pull,_and_Approve_Process|Push, Pull, or Approve]] before actual merging. This project provides unique tools to examine the proposed changes of a Push or Pull and enables users to modify their project without affecting the destination of the merge. The objectives of a Review Project are to:
* Allow data modeling prior to finalizing the merge
* Facilitate a thorough review of incoming changes
* Provide additional pages to aid the review process

== Review Project Management ==
To learn about the creation of Review Projects, view the [[Push,_Pull,_and_Approve_Process|Push, Pull, and Approve Process]].

When in PHENOM > Manage Models > Projects, the user can view the Review Projects they have access to under the destination Project within the Project Tree. Expand the destination Project in the Project Tree, then expand the Review Projects folder.

[[File:ReviewProjectInTree2.png|600px|border]]

To view the corresponding push/pull request for your Review Project, simply select the Review Project from the Project Tree. The user can also access the the related Review Project for a push/pull request either on the pull or on the approve page where the Review Project was initiated.

[[File:ReviewProjectSelect.png|1000px|border]]

Review projects can be modified like standard projects but cannot be copied, published, or restructured (changing the Models). Additionally, the [[Push,_Pull,_and_Approve_Process|Push, Pull, and Approve pages]] are consolidated into the Review Tab when switched to a Review Project, which contains [[Review_Projects#Review_Project_Specific_Pages| pages specific to the Review Project]].

== Project Locking ==
When initiating a Review Project from either the pull or approve page, users have the option to secure the destination Project by selecting 'Lock Current Project During Review'. This lock ensures that no changes can be made to the modeling content while it's under review. Once the merge is ready to be finalized, the Project lock must be removed to finalize the merge. Multiple Review Projects can exist simultaneously so it is important for the user to manage the single lock on the destination Project during review.
 

Note that while Project locking is optional, it is encouraged to use the Project lock to prevent external changes being made to the destination Project during review.

[[File:ProjectLocking.png|1000px|border]]

== Review Project Specific Pages ==
=== Finalize Merge ===
The Finalize Merge page serves as a central hub where users can finalize their merge and review the changes they've selected, either from the initial Review Project creation or from updates made on the [[Review_Project#Update_Review|Update Review page]]. Users may create a Commit directly from the Finalize Merge page, allowing them to establish a safety net before [[Review_Project#Accepting,_Rejecting,_&_Reviewing_Changes|accepting or rejecting]] changes, without having to visit the [[Review Project#Checkpoints|Checkpoints page]].
 

Accessed from a Review Project in PHENOM > Manage Models > Review > Finalize Merge, as seen below:

[[File:FinalizeMerge2.png|1000px|border]]

The 'Review Nodes' list connects each review change to its parent, as links, if available. This list lets users quickly access the change's details page to see the specific updates. Users can also view the review status from the Finalize Merge page, NavTree or the details page. For guidance on changing the review status of a change and or its children, please refer to the section on [[Review_Project#Accepting,_Rejecting,_&_Reviewing_Changes|accepting, rejecting, & reviewing Changes]].

Once users have altered the review status of proposed changes and other review project content, they can complete the merge process by clicking the 'Finalize Merge' button located in the top bar. Finalizing the merge will implement all pending and accepted changes, as well as any additional modifications made during the review process. Additionally the destination Project may be unlocked while finalizing the merge.

[[File:FinalizeMergeFinalize.png|1000px|border]]

Below is an example of the finalize merge confirmation where there are pending changes and the destination project is locked. To proceed with the merge, the user should click 'Yes'. To review the remaining changes or make other edits, click 'No'.

[[File:ConfirmFinalizeMerge.png|350px|border]]

If the destination Project isn't locked and has been altered during the review, a rebase will be required. Rebasing synchronizes the current review with the latest changes from the destination Project. After rebasing, the user can restart the process of finalizing the merge.

[[File:Rebase2.png|350px|border]]

=== Checkpoints ===
The Checkpoints page lists each Checkpoint for the Review Project. Checkpoints enable users to roll back the Review Project to a previous version, reflecting the model content as it was at the time the Checkpoint was created.
 

Accessed from a Review Project in PHENOM > Manage Models > Review > Checkpoint, as seen below:

[[File:CommitsInit.png|1000px|border]]

When the Review Project is initiated, an initial Checkpoint is always created. Additionally, the user can create a Checkpoint at any time during the review from the Checkpoint page or before rejection of review changes.
 

Users can rollback to any Checkpoint at any time. It's crucial to understand that rolling back to a Checkpoint will delete all subsequent Checkpoints and revert any changes made after that Checkpoint. To rollback to a Checkpoint, simply select the desired Checkpoint from the list, then click the 'Rollback To Checkpoint' icon located in the top bar of the page:

[[File:CommitRollback.png|1000px|border]]

=== Update Review ===
The Update Review page is very similar to the pull page found in the [[Push,_Pull,_and_Approve_Process|Push, Pull, and Approve Process]]. Users can select additional changes from the push/pull request that were not initially chosen during the creation of the Review Project. These changes can either be accepted or ignored.
 

Accessed from a Review Project in PHENOM > Manage Models > Review > Update Review, as seen below:

[[File:UpdateReview2.png|1000px|border]]

Here you will be prompted to select nodes from the tree on the left or from the Merge Summary. You may choose to ignore certain changes and accept others. Any changes accepted will overwrite your current version of those model elements.

== Accepting, Rejecting, & Reviewing Changes ==
These actions are crucial for managing proposed review changes and are accessible from the [[Review_Project#Finalize_Merge|Finalize Merge page]] or the details page of a proposed change.

=== Accepting Changes ===
All proposed changes are initially pending and cannot be edited until accepted. Accepting a pending change indicates it is ready for merging. Once accepted and edited, the proposed change may not be reverted back to pending. Please note that pending changes will be automatically accepted when finalizing the merge.

Click the check icon to accept changes: [[File:AcceptBtn.png|150px|border]]

[[File:DetailsAccept.png|1000px|border]]

Click the question mark icon to revert accepted changes back to pending:
[[File:UnacceptBtn.png|105px|border]]

[[File:DetailsUnAccept.png|1000px|border]]

=== Rejecting Changes ===
Rejecting a pending change will instantly restore it to its original state. Only changes that are still pending can be rejected. To safeguard against the irreversible nature of rejection, it is strongly advised to make a Commit before rejecting any changes.

Click the x-mark icon to reject changes: [[File:RejectBtn.png|150px|border]]

[[File:DetailsReject.png|1000px|border]]

=== Reviewing Changes ===
Reviewing a change with the 'Review of Proposed Changes' popup enables users to compare the original state with the current proposed modifications. Differences are highlighted in bold in the proposed changes column.

Click the magnifying glass icon to review changes: [[File:ReviewBtn.png|152px|border]]

Below is an example of reviewing proposed changes with edits.

[[File:PreviewPopup.png|850px|border]]

Review Project

2025-05-13T18:42:11Z

Josh: /* Checkpoints */

== Review Projects 101 ==
A '''Review Project''' in PHENOM is a temporary workspace created to show the user the outcome of a [[Push,_Pull,_and_Approve_Process|Push, Pull, or Approve]] before actual merging. This project provides unique tools to examine the proposed changes of a Push or Pull and enables users to modify their project without affecting the destination of the merge. The objectives of a Review Project are to:
* Allow data modeling prior to finalizing the merge
* Facilitate a thorough review of incoming changes
* Provide additional pages to aid the review process

== Review Project Management ==
To learn about the creation of Review Projects, view the [[Push,_Pull,_and_Approve_Process|Push, Pull, and Approve Process]].

When in PHENOM > Manage Models > Projects, the user can view the Review Projects they have access to under the destination Project within the Project Tree. Expand the destination Project in the Project Tree, then expand the Review Projects folder.

[[File:ReviewProjectInTree2.png|600px|border]]

To view the corresponding push/pull request for your Review Project, simply select the Review Project from the Project Tree. The user can also access the the related Review Project for a push/pull request either on the pull or on the approve page where the Review Project was initiated.

[[File:ReviewProjectSelect.png|1000px|border]]

Review projects can be modified like standard projects but cannot be copied, published, or restructured (changing the Models). Additionally, the [[Push,_Pull,_and_Approve_Process|Push, Pull, and Approve pages]] are consolidated into the Review Tab when switched to a Review Project, which contains [[Review_Projects#Review_Project_Specific_Pages| pages specific to the Review Project]].

== Project Locking ==
When initiating a Review Project from either the pull or approve page, users have the option to secure the destination Project by selecting 'Lock Current Project During Review'. This lock ensures that no changes can be made to the modeling content while it's under review. Once the merge is ready to be finalized, the Project lock must be removed to finalize the merge. Multiple Review Projects can exist simultaneously so it is important for the user to manage the single lock on the destination Project during review.
 

Note that while Project locking is optional, it is encouraged to use the Project lock to prevent external changes being made to the destination Project during review.

[[File:ProjectLocking.png|1000px|border]]

== Review Project Specific Pages ==
=== Finalize Merge ===
The Finalize Merge page serves as a central hub where users can finalize their merge and review the changes they've selected, either from the initial Review Project creation or from updates made on the [[Review_Project#Update_Review|Update Review page]]. Users may create a Commit directly from the Finalize Merge page, allowing them to establish a safety net before [[Review_Project#Accepting,_Rejecting,_&_Reviewing_Changes|accepting or rejecting]] changes, without having to visit the [[Review_Project#Commits|Commits page]].
 

Accessed from a Review Project in PHENOM > Manage Models > Review > Finalize Merge, as seen below:

[[File:FinalizeMerge2.png|1000px|border]]

The 'Review Nodes' list connects each review change to its parent, as links, if available. This list lets users quickly access the change's details page to see the specific updates. Users can also view the review status from the Finalize Merge page, NavTree or the details page. For guidance on changing the review status of a change and or its children, please refer to the section on [[Review_Project#Accepting,_Rejecting,_&_Reviewing_Changes|accepting, rejecting, & reviewing Changes]].

Once users have altered the review status of proposed changes and other review project content, they can complete the merge process by clicking the 'Finalize Merge' button located in the top bar. Finalizing the merge will implement all pending and accepted changes, as well as any additional modifications made during the review process. Additionally the destination Project may be unlocked while finalizing the merge.

[[File:FinalizeMergeFinalize.png|1000px|border]]

Below is an example of the finalize merge confirmation where there are pending changes and the destination project is locked. To proceed with the merge, the user should click 'Yes'. To review the remaining changes or make other edits, click 'No'.

[[File:ConfirmFinalizeMerge.png|350px|border]]

If the destination Project isn't locked and has been altered during the review, a rebase will be required. Rebasing synchronizes the current review with the latest changes from the destination Project. After rebasing, the user can restart the process of finalizing the merge.

[[File:Rebase2.png|350px|border]]

=== Checkpoints ===
The Checkpoints page lists each Checkpoint for the Review Project. Checkpoints enable users to roll back the Review Project to a previous version, reflecting the model content as it was at the time the Checkpoint was created.
 

Accessed from a Review Project in PHENOM > Manage Models > Review > Checkpoint, as seen below:

[[File:CommitsInit.png|1000px|border]]

When the Review Project is initiated, an initial Checkpoint is always created. Additionally, the user can create a Checkpoint at any time during the review from the Checkpoint page or before rejection of review changes.
 

Users can rollback to any Checkpoint at any time. It's crucial to understand that rolling back to a Checkpoint will delete all subsequent Checkpoints and revert any changes made after that Checkpoint. To rollback to a Checkpoint, simply select the desired Checkpoint from the list, then click the 'Rollback To Checkpoint' icon located in the top bar of the page:

[[File:CommitRollback.png|1000px|border]]

=== Update Review ===
The Update Review page is very similar to the pull page found in the [[Push,_Pull,_and_Approve_Process|Push, Pull, and Approve Process]]. Users can select additional changes from the push/pull request that were not initially chosen during the creation of the Review Project. These changes can either be accepted or ignored.
 

Accessed from a Review Project in PHENOM > Manage Models > Review > Update Review, as seen below:

[[File:UpdateReview2.png|1000px|border]]

Here you will be prompted to select nodes from the tree on the left or from the Merge Summary. You may choose to ignore certain changes and accept others. Any changes accepted will overwrite your current version of those model elements.

== Accepting, Rejecting, & Reviewing Changes ==
These actions are crucial for managing proposed review changes and are accessible from the [[Review_Project#Finalize_Merge|Finalize Merge page]] or the details page of a proposed change.

=== Accepting Changes ===
All proposed changes are initially pending and cannot be edited until accepted. Accepting a pending change indicates it is ready for merging. Once accepted and edited, the proposed change may not be reverted back to pending. Please note that pending changes will be automatically accepted when finalizing the merge.

Click the check icon to accept changes: [[File:AcceptBtn.png|150px|border]]

[[File:DetailsAccept.png|1000px|border]]

Click the question mark icon to revert accepted changes back to pending:
[[File:UnacceptBtn.png|105px|border]]

[[File:DetailsUnAccept.png|1000px|border]]

=== Rejecting Changes ===
Rejecting a pending change will instantly restore it to its original state. Only changes that are still pending can be rejected. To safeguard against the irreversible nature of rejection, it is strongly advised to make a Commit before rejecting any changes.

Click the x-mark icon to reject changes: [[File:RejectBtn.png|150px|border]]

[[File:DetailsReject.png|1000px|border]]

=== Reviewing Changes ===
Reviewing a change with the 'Review of Proposed Changes' popup enables users to compare the original state with the current proposed modifications. Differences are highlighted in bold in the proposed changes column.

Click the magnifying glass icon to review changes: [[File:ReviewBtn.png|152px|border]]

Below is an example of reviewing proposed changes with edits.

[[File:PreviewPopup.png|850px|border]]

Formatting a CSV for View Import

2024-04-30T20:12:49Z

Josh: /* Column-specific Requirements */ Specify how to create nested views via CSV import

To bulk import view characteristics, the CSV file should be formatted as described in this article.

== General Column/Data Requirements ==
The following column headers must exist and contain data in each row:
* View_Name
* Characteristic_Name
* Primitive
* Source
* Path
* Measurement

The following columns are optional (for example, the Package columns are only there to specify destination if desired):
* Package_Name
* Package_Description
* Package_Tags
* View_Description
* View_Tags
* Characteristic_Description
* Characteristic_Tags
* Lower_Bound
* Upper_Bound
* Nested_View

The order of the columns is not enforced, it does not have to be in the same order as the suggested format above.

Any additional user-made columns will be ignored and will not interfere with import.

Bulk import can currently import Package, View, and Characteristic elements.

== Column-specific Requirements ==
=== Package Name ===
* Leaving this column blank will default Package to the "Phenom" package.
* Setting this column to an existing Package will default to the first matching Platform Package within the model.
* If there is no matching Package, a new Package will be created within the "Phenom" Package.

=== Package Description ===
Package Description will be imported for new Packages only. Only the first Description for new Packages will be imported.

=== View Name ===
The data in this column for an existing View will be matched to the first View of that name within the model (there should only be one match). If there isn't a matching View, a new View will be created within the "Phenom" Package.

=== View Description ===
View Description will be imported for new Views only. Only the first Description for new Views will be imported.

=== Characteristic Name, Characteristic Description ===
* Characteristic Names must be unique to the View they are imported under.
* The Characteristic must not already exist in the desired View
* Characteristics belonging to different Views may have the same name.

=== Primitive ===
This column isn't case sensitive. Acceptable values: "Char", "Double", "Float", "Long", "Short", "String", "ULong", "UShort", "Octet", "Enumeration".

=== Source, Path, Measurement ===
* Source must exist in the model and must be the Entity/Association projected from the last element in the Path column.
* Path must have valid elements leading up to/ending with the Observable realized by the Measurement.
* Measurement must in the model and realize the Observable at the end of the Path.

''For example: '''AirSystemType''' is projected (through payload) from '''elementID''' which is realized by ''UniqueID_Unbounded_Integer'

=== Lower Bound and Upper Bound ===

* This row must have both a Source and a Path for these values to be valid

=== Nested View ===

* The Nested View must exist in the model and must be the name of a View.
* See Nested Views for changes to other columns

== Tagging New Elements (Optional) ==
Package_Tags, View_Tags, and Characteristic_Tags optional columns can be used to tag new Packages, Views, or Characteristics. Each field can have multiple comma-delimited tags.

The raw CSV must have quotes around fields with commas (Excel normally handles this).

Package_Tags will tag whichever package is chosen - this includes the Phenom package when a package isn't specified in the Package_Name column.

== Nested Views ==
In order to create a nested view attribute, the Nested_View column will need to reference an existing view in the model.

For nested views, the Primitive, Platform_Type, and Measurement columns cannot have a value.

For nested views, the Source now corresponds to the Perspective of the nested view.

== Additional Requirements ==
* Data within Package_Name, View_Name, and Characteristic_Name must all begin with a letter, and only contain numbers, letters, or underscores. The data must also not match any of the following reserved words:
** '''IDL Reserved words:'''"and", "begin", "break", "case", "common", "compile_opt", "continue", "do", "else", "end", "endcase", "endelse", "endfor", "endforeach", "endif", "endrep", "endswitch", "endwhile", "eq", "for", "foreach", "forward_function", "function", "ge", "goto", "gt", "if", "inherits", "le", "lt", "mod", "ne", "not", "of", "on_ioerror", "or", "pro", "repeat", "switch", "then", "until", "while", "xor"
** '''OCL Reserved words:''' "abstract", "any", "attribute", "boolean", "case", "char", "component", "const", "consumes", "context", "custom", "default", "double", "emits", "enum", "eventtype", "exception", "factory", "false", "finder", "fixed", "float", "getraises", "home", "import", "in", "inout", "interface", "local", "long", "manages", "module", "multiple", "native", "object", "octet", "oneway", "out", "primarykey", "private", "provides", "public", "publishes", "raises", "readonly", "sequence", "setraises", "short", "string", "struct", "supports", "switch", "true", "truncatable", "typedef", "typeid", "typeprefix", "union", "unsigned", "uses", "valuebase", "valuetype", "void", "wchar", "wstring"
* New Views not already within the model must be unique among elements of type IDLStruct and Enumeration.
* Multidimensional Measurements are supported, however each axis will default to the primitive found within the primitive column (these can be corrected within Phenom later if desired).
* If there are any errors during validation of the CSV file, the model import will not be initiated and a list of errors will be returned. They will be labeled by the row they occur on for convenience.
* There is a 2MB limit in place - if a larger file needs to be imported, it needs to be split up into smaller files.
* In the raw CSV (i.e., as observed from notepad), any field with commas must have surrounding quotes (Excel normally handles this).

Permissions

2024-04-30T15:06:51Z

Josh: /* Admin Permissions */ Update phrasing to reflect changes to Admin

Permissions are a user's access level to either a project or a model. There are four different types of permissions, and a user can have any of the permissions types independent of one another.
Permissions on a project and the models it contains are distinct (i.e., the user can have different permissions (higher or lower) at the project level compared to the models).

= Permissions Types =
== Read Permissions ==
'''If a user has Read permissions, they have read-only access to the project or model.'''

Having Read permissions to a project and its models allows the user to switch to that project, see all the content, export the content, but not create, edit, or update it. In addition, if the model inherits from another model, a user with Read permissions is allowed to see the nodes that can be pulled from a parent model, but are prevented from actually pulling that content. Likewise, if a model has other models that inherit from it, a user with Read permissions to the model is allowed to see the push requests from the children models, but is not allowed to approve those changes.

Read permissions are unique from the other permissions types in that they are required in order to have any other permissions. For that reason, when assigning Write, Admin, or Owner permissions, Read permissions are assigned by default and can't be removed, as seen below.

[[File:Perms5 2.png|frameless|636x636px]]

== Write Permissions ==
'''If a user has Write permissions, they are allowed to edit project and model content.'''

Having Write permissions to a project or a model allows the user to modify any of its content, including pulling, pushing, and approving push requests. Note that to pull changes from a parent model, the user needs at least Read permissions to the parent model.

== Admin Permissions ==
'''If a user has Admin permissions, they are allowed to share the project or model and inherit from it'''

Having Admin permissions to a project or a model allows the user to create inheriting projects or models. Admin users can also assign permissions types (provided the user has those types) of other users belonging to their own account for this project or model

== Owner Permissions ==
'''If a user has Owner permissions, they have the same permissions as Admins, as well as some additional actions.'''

Having Owner permissions to a project or a model provide the user with Admin permissions plus the ability to delete the project or model, to change the metadata of it, and to share it with users external to their account. Owner users can grant all permissions types (provided the user has those types) for internal users, including Owner, while the user may only assign Read, Write, and Admin for external users.

= Assign Permissions =
== Assign Permissions to Internal Users ==
Users are able to assign permissions to their projects or models by using the Permission Manager on the Project or Model Details page. The table lists all the users from the same account as the current user.

[[File:Perms1.png|alt=Project Details Page Permissions Manager|frameless|1023x1023px]]

To be able to share a Model, users need to have Admin or Owner permissions to it. The types of permissions users can grant depend on the the permissions they have to the model.

To be able to share a Project, users need to have Admin or Owner permissions to it and to all the models it contains. The types of permissions users can grant depend on the the permissions they have to the project and its models. The type permissions granted for the project will be applied to all its models.

{| class="wikitable"
! Current User Permissions !! Target User Permissions Options
|-
| Read + Admin || Read, Admin
|-
| Read + Admin + Owner|| Read, Admin, Owner
|-
| Read + Write + Admin || Read, Write, Admin
|-
| Read + Write + Admin + Owner|| Read, Write, Admin, Owner
|}

== Assign Permissions to External Users ==
To assign permissions to users that do not belong to the current user's account, the user has to give them a Permissions Token. The procedure to do so is as follows:
* Go to the Project Sharing page
* Locate the project or model to be shared
* Enter the username and the desired permissions level*
* Click the Share button
* Email the generated Token (which appeared on the right of the screen) to the user.
Note that the Token is only valid for 24 hours.

* The types of permissions users can grant follow the same policy as for internal users (see table above) except that they can't grant Owner permissions even if they have Owner permissions themselves.

[[File:Perms2.png|alt=Project Sharing Page|frameless|1027x1027px]]

To gain access to the project or model, the user has to go to the Project Sharing page, copy the Token received by email in the dedicated field and click the Submit button. The new project or model should then appear in the their project/model tree.

[[File:Perms3.png|alt=Accepting Perms Token|frameless|597x597px]]

This user, along with any other external users, will appear in the Permissions Manager under a separate External Users table.

[[File:Perms4.png|alt=Project Details with External Users Permissions|frameless|599x599px]]

== Account Admins ==
Account admins are able to see all the projects and models that users from their account have access to, and are able to assign permissions to those projects and models to any user in their account.

For internally created projects or models, Account admins can grant any types of permissions (including Owner) to any user in their account.

For a project or model that was externally shared with one (or more) of their account users, the Account admin can only assign permissions to other users if at least one of those original users was granted Admin permissions. In addition, if no one was granted Write access to the project or model, then Account admins will not be allowed to grant Write permissions to anyone, only Read and Admin.

Permissions

2024-04-30T14:51:35Z

Josh: /* Read Permissions */ Updated image to include new editing of O perms function

Permissions are a user's access level to either a project or a model. There are four different types of permissions, and a user can have any of the permissions types independent of one another.
Permissions on a project and the models it contains are distinct (i.e., the user can have different permissions (higher or lower) at the project level compared to the models).

= Permissions Types =
== Read Permissions ==
'''If a user has Read permissions, they have read-only access to the project or model.'''

Having Read permissions to a project and its models allows the user to switch to that project, see all the content, export the content, but not create, edit, or update it. In addition, if the model inherits from another model, a user with Read permissions is allowed to see the nodes that can be pulled from a parent model, but are prevented from actually pulling that content. Likewise, if a model has other models that inherit from it, a user with Read permissions to the model is allowed to see the push requests from the children models, but is not allowed to approve those changes.

Read permissions are unique from the other permissions types in that they are required in order to have any other permissions. For that reason, when assigning Write, Admin, or Owner permissions, Read permissions are assigned by default and can't be removed, as seen below.

[[File:Perms5 2.png|frameless|636x636px]]

== Write Permissions ==
'''If a user has Write permissions, they are allowed to edit project and model content.'''

Having Write permissions to a project or a model allows the user to modify any of its content, including pulling, pushing, and approving push requests. Note that to pull changes from a parent model, the user needs at least Read permissions to the parent model.

== Admin Permissions ==
'''If a user has Admin permissions, they are allowed to make changes to projects and models themselves.'''

Having Admin permissions to a project or a model allows the user to change the metadata of the project or model and create inheriting projects or models. They can also set the permissions of other users (belonging to their own account) to this project or model up to Admin.

== Owner Permissions ==
'''If a user has Owner permissions, they have the same permissions as Admins, as well as some additional actions.'''

Having Owner permissions to a project or a model provide the user with Admin permissions plus the ability to delete the project or model, and to share it with users external to their account. Owner users can grant permissions up to Owner for internal users and Admin for external users.

= Assign Permissions =
== Assign Permissions to Internal Users ==
Users are able to assign permissions to their projects or models by using the Permission Manager on the Project or Model Details page. The table lists all the users from the same account as the current user.

[[File:Perms1.png|alt=Project Details Page Permissions Manager|frameless|1023x1023px]]

To be able to share a Model, users need to have Admin or Owner permissions to it. The types of permissions users can grant depend on the the permissions they have to the model.
To be able to share a Project, users need to have Admin or Owner permissions to it and to all the models it contains. The types of permissions users can grant depend on the the permissions they have to the project and its models. The type permissions granted for the project will be applied to all its models.

{| class="wikitable"
! Current User Permissions !! Target User Permissions Options
|-
| Read + Admin || Read, Admin
|-
| Read + Admin + Owner|| Read, Admin, Owner
|-
| Read + Write + Admin || Read, Write, Admin
|-
| Read + Write + Admin + Owner|| Read, Write, Admin, Owner
|}

== Assign Permissions to External Users ==
To assign permissions to users that do not belong to the current user's account, the user has to give them a Permissions Token. The procedure to do so is as follows:
* Go to the Project Sharing page
* Locate the project or model to be shared
* Enter the username and the desired permissions level*
* Click the Share button
* Email the generated Token (which appeared on the right of the screen) to the user.
Note that the Token is only valid for 24 hours.

* The types of permissions users can grant follow the same policy as for internal users (see table above) except that they can't grant Owner permissions even if they have Owner permissions themselves.

[[File:Perms2.png|alt=Project Sharing Page|frameless|1027x1027px]]

To gain access to the project or model, the user has to go to the Project Sharing page, copy the Token received by email in the dedicated field and click the Submit button. The new project or model should then appear in the their project/model tree.

[[File:Perms3.png|alt=Accepting Perms Token|frameless|597x597px]]

This user, along with any other external users, will appear in the Permissions Manager under a separate External Users table.

[[File:Perms4.png|alt=Project Details with External Users Permissions|frameless|599x599px]]

== Account Admins ==
Account admins are able to see all the projects and models that users from their account have access to, and are able to assign permissions to those projects and models to any user in their account.

For internally created projects or models, Account admins can grant any types of permissions (including Owner) to any user in their account.

For a project or model that was externally shared with one (or more) of their account users, the Account admin can only assign permissions to other users if at least one of those original users was granted Admin permissions. In addition, if no one was granted Write access to the project or model, then Account admins will not be allowed to grant Write permissions to anyone, only Read and Admin.

File:Perms5 2.png

2024-04-30T14:50:01Z

Josh:

Grayed out R permissions

Permissions

2024-04-22T03:05:41Z

Josh: /* Owner Permissions */ Added screenshots, changed some text based on changed functionality

== General ==
Permissions are a user's access level to either a project or a model. There are four different types of permissions, and a user can have any of the permissions types independent of one another. Users are able to assign permissions to their projects and models by using the Permissions Manager on the Project Detail and Model Detail pages. The table contains all users on the same account as the user.

[[File:Perms1.png|alt=Project Details Page Permissions Manager|frameless|1023x1023px]]

Another way to assign permissions to users that do not belong to the current user's account is by giving them a Permissions Token via the Project Sharing page. By inputting a username and the desired permissions level, then clicking the Share button, a unique Token will be generated for the specified user.

[[File:Perms2.png|alt=Project Sharing Page|frameless|1027x1027px]]

The other user can then input the generated token to gain access to that project or model.

[[File:Perms3.png|alt=Accepting Perms Token|frameless|597x597px]]

This user, along with any other external users, will appear in the Permissions Manager under a separate External Users table.

[[File:Perms4.png|alt=Project Details with External Users Permissions|frameless|599x599px]]

== Read permissions ==
'''If a user has Read permissions, they have the most basic access to a project or model.'''

The user is allowed to switch to a project to which they have Read permissions to all the contained models. The user is allowed to see all the content of their Read access projects and models. The user is also allowed to export their project for use elsewhere. In addition, if the model inherits from another model, a user with Read permissions is allowed to see the nodes that can be pulled from a parent model, but are prevented from actually pulling that content. Likewise, if a model has other models that inherit from it, a user with Read permissions to the model is allowed to see the push requests from the children models, but is not allowed to approve those changes.

Read permissions are also unique from the other permissions types because in order to have any other permissions, a user is required to also have Read access, to prevent scenarios where a user is allowed to edit model content that they are not even allowed to see. This is why a user wanting to assign Write or Admin permissions are not allowed to disable Read permissions, as seen below.

[[File:Perms5.png|alt=Uncheckable Read Permissions Boxes|frameless|742x742px]]

== Write Permissions ==
'''If a user has Write permissions, they are allowed to edit project and model content.'''

The user is able to modify fields on the details pages of nodes in the model, as well as the majority of the actions related to inheriting models. If the model inherits from another model, the user with Write access is able to request to push content to the parent model. Assuming that the user also has Read permissions to the parent model, the user is also allowed to pull any new changes from the parent model. Likewise, if a model has other models that inherit from it, a user with Write permissions to the model is allowed to approve content changes and delete push requests.

== Admin Permissions ==
'''If a user has Admin permissions, they are allowed to make changes to projects and models themselves.'''

A user who has Admin access to projects or models is allowed to change the permissions of users who belong to the same account as them to the project or model, up to their own level of Admin. A user with Admin access to a model is also allowed to create inheriting models from it. A user who is an Admin for a project or model is also allowed to rename those projects and models.

== Owner Permissions ==
'''If a user has Owner permissions (or "owns" a project or model), they were the creator of the project or model, and therefore have all of the above permissions types, as well as some more actions limited to just the owner of the project or model.'''

A user that owns a project or model is allowed to change permissions, both to users that belong to the same account as them (up to Owner level), as well as external users, sharing permissions with them via Permissions Tokens (up to Admin level). If a user owns a project and wishes to give other users permissions to it that are higher than those users currently have, the user must also have Admin permissions to all the contained models. In addition, the Owner of a project or model is the only user allowed to delete the projects and models they own.

It should be noted that if a project or model was created before April 2nd, 2024, the project or model may have more than one Owner. When Owner permissions were added, the Owner of a given project or model was determined to be anyone who had Admin permissions to that project or model, excluding any user who recieved Admin access via a Permissions Token. All projects and models created after April 2nd, 2024, only have one Owner.

== Account Admins ==
Account admins are able to see all the projects and models that exist on their account, and are able to assign permissions to those projects and models to any user on the same account. In the case that a project or model was shared to someone on an account using a Permissions Token, that account's Admins are only allowed to assign permissions to the project or model that someone on the account holds.

File:Perms5.png

2024-04-22T03:04:51Z

Josh:

Uncheckable Read Permissions Boxes

File:Perms4.png

2024-04-22T03:03:36Z

Josh:

Project Details with External Users Permissions

File:Perms3.png

2024-04-22T03:02:37Z

Josh:

Accepting Perms Token

File:Perms2.png

2024-04-22T02:58:00Z

Josh:

Project Sharing Page

File:Perms1.png

2024-04-22T02:54:43Z

Josh:

Project Details Permissions Manager

Projects and Models Management

2024-04-18T17:26:11Z

Josh: /* Projects Management */ Updated screenshots for new permissions UI

== Projects & Models 101 ==
A '''project''' in PHENOM is composed of one or more models which are loaded together into a workspace.
A '''model''' is a collection of nodes. A node can be an entity, an association, an observable, a view…
One objective of a project is to be:
* Independent
* Complete: reflect the reality to the best of its ability
* Compliant
* Valid (or at least "validatable ")
A model in and of itself might not constitute a complete, compliant, or even valid project as it might depend on entities inside other models, making it impossible to load independently. However, by combining several models in a project, they can form a complete, compliant, and valid model.

[[File:Phenom-manage-project model structure1.png|600px|border]]

The following diagram depicts how a model can be part of multiple projects.

[[File:Phenom-manage-project model structure2.png|600px|border]]

Once a project is loaded into PHENOM, the node contents of its constituent models can be added to as well as edited.

== Projects Management ==
When in PHENOM > Manage Models > Projects, the user can see the projects and models he has access to.

[[File:Phenom-manage-projects models list.png|500px|border]]

The project you are currently working on is displayed at the top of all the pages. Additionally, in the Manage Projects page, the active project is the expanded by default and has a different icon.

[[File:Phenom-manage-active project.png|600px|border]]

To create a project, the user can click on the + button in the Projects list and then select existing models, import new FACE models, or add new blank models.

[[File:Phenom-manage-new project.png|600px|border]]

There are three ways a user can have access to a project or a model:
* He creates it
* He uploads it
* Another user gives him permission to it
The user will see, for each model, its inheritors and versions.

The user can easily switch between projects in the Projects Management page.

[[File:Phenom-manage-switch-project-2.png|border|800x800px]]

== Model Versions ==
In PHENOM, models maintain the content as well as the record of changes made to that content.

By default, each model has a "live" version. This is the version of the model which, when loaded in a project can be edited and amended.

When the user is satisfied with the current state of a model, he can publish it, thus creating a “static” version of that model. A published version of a model is a snapshot of its content at one point in time. It cannot be added to or edited but can still be included in a project, referenced by and depended upon by the contents of a different model.

In the example below, the model version FACE_SDM_306 and FACE_SDM_316 are a "published" version of the FACE_SDM model. While it can be shared with other users, included in a project, and referred to and depended upon by other models, it can never be edited. In the Model tree, all published models have their publication dates displayed for ease of use.

[[File:Phenom-manage-published model.png|600px|border]]

== Model Inheritance & Content Merging ==
The same model can be loaded as a part of several different projects. However, the users of those projects will not be able to edit the content of the model simultaneously.
When a user chooses to include in a project a model which is already a part of a different project, a "child" model will be created. This inheriting or "child" model is not a different version of a model, but rather its own model which inherits some portion of its content.
At first, the inheriting and the parent models are identical but as their respective user make changes, they grow apart. Therefore, it’s possible for this "child" model to merge its changes to and from the parent model.
A user can see the relationships between models in Manage Models > Projects > Model.
In this example, the model Coffee is the parent of the model Coffee_in_Coffee_2. This results from the Coffee_live version of the Coffee model being loaded into a new project. When edits are made in either the parent or child model, the changes can be merged between them.

[[File:Phenom-manage-model branching.png|600px|border]]

Clicking on a live or published model will display its characteristics on the right panel. The user will be able to edit some of the model's characteristics and the permissions of the model, provided he has Admin or Owner privileges for that model.

[[File:Phenom-manage-model details2.png|border|800x800px]]

== Sample Workflow ==
This section goes over a sample workflow which employs the PHENOM project and model structure concepts described in the sections above.
In the scenario laid out below, a group of users, Chris, Dave, Nick, and Riley are working on different parts of completing a data model and documenting a set of interfaces against it. Each of them plays a slightly different role in the process, and they will use some of PHENOM's Model management features to keep their work organized.

=== Part 1 – Chris ===
Chris is working on updating the Shared Data Model (SDM) the group is using to conform to the latest changes released in an accepted standard. He loads an SDM content file to create a model.

[[File:Phenom-manage-example chris 1.png|600px|border]]

[[File:Phenom-manage-example chris 2.png|300px|border]]

He loads the model into an SDM_Editor project and begins to make the changes.

[[File:Phenom-manage-example chris 3.png|600px|border]]

[[File:Phenom-manage-example chris 4.png|300px|border]]

Once he has made the changes necessary to match a decided-upon standard, he publishes a version v1 of his SDM model.

[[File:Phenom-manage-example chris 5.png|300px|border]]

[[File:Phenom-manage-example chris 6.png|300px|border]]

Chris is going to make further changes in the SDM_Editor project, but that will be for the next standard update. In the meantime, he wants to make the static version of the SDM he just published available to the rest of his team, so he gives them Read permissions to it. However, making further changes to the SDM is his job and he wants to stay in control of the process, so he does not give any of his colleagues permissions to either the live version of the SDM model or the SDM_Editor project.

[[File:Phenom-manage-example-chris-7.png|border|829x829px]]

=== Part 2 – Dave ===
Dave is working on creating a Domain Specific Data Model (DSDM) for the team to use - he will be referencing the SDM Chris released in his efforts. He creates a new project into which he adds the SDM version he has access to and a blank model which will contain the DSDM content he creates.

[[File:Phenom-manage-example dave 1.png|600px|border]]

After he has added some content to his DSDM model which references nodes in the SDM, he will see that his DSDM model is now listed as dependent on the SDM model he has been using – which means, it can no longer be loaded without it.

[[File:Phenom-manage-example dave 2.png|600px|border]]

[[File:Phenom-manage-example dave 3.png|600px|border|]] Note that the model section at the top right of the page lists DSDM_live as the home of the Engine entity

Nick and Riley will be documenting some interfaces against the domain model that Dave is working on. However, Dave does not want them to have to wait for him to have finished with all of his work before they can start. Also, as they work on their interface documentation, they may come up with good changes to the DSDM and suggest that they be included in Dave's work. So, Dave decided to share his project with Nick and Riley, giving them Read/Write permissions, which automatically gives them permissions to the active DSDM model version he's working on.

[[File:Phenom-manage-example-dave-4.png|border|812x812px]]

=== Part 3 – Nick & Riley ===
Nick and Riley will be documenting interfaces using the DSDM that was shared with them, but they will be working with different sets of interfaces, each in his own project.
If they try to create a new project with just the DSDM, they will be rejected because they must also load in the SDM that was used to create it and on which it depends.

[[File:Phenom-manage-example nick riley 1.png|600px|border]]

Once they have the appropriate permissions to all of the content, they can create their individual project with the models to house their documentation work separate from the contents of both the SDM and the DSDM.
In the example below, Riley creates a RILEY_s_INTFC_DOC project including the DSDM_live model and a new blank model for his changes. By doing so, a new model, DSDM_IN_RILEY_S_INTFC_DOC, was created, inheriting from Dave’s DSDM_live.

[[File:Phenom-manage-example nick riley 2.png|600px|border]]

Dave and Riley will now be able to independently edit DSDM content and merge changes between their two models as they see appropriate.
Whenever Dave makes new updates to the DSDM, Nick and Riley have the opportunity to pull in those changes into their copies of the model. When either one of them makes a change to the DSDM portion of his project that he thinks should be included in the official version, they can make a push request to Dave's project that he can then either approve or ignore.

File:Phenom-manage-example-dave-4.png

2024-04-18T17:24:48Z

Josh:

Dave workflow example

File:Phenom-manage-example-chris-7.png

2024-04-18T17:23:54Z

Josh:

Chris workflow example

File:Phenom-manage-model details2.png

2024-04-18T17:22:27Z

Josh:

Phenom model details example

File:Phenom-manage-switch-project-2.png

2024-04-18T17:20:46Z

Josh:

Phenom switch to project UI example

Permissions

2024-04-02T16:48:27Z

Josh: Bolded instead of making highlight text a sub-heading

== General ==
Permissions are a user's access level to either a project or a model. There are four different types of permissions, and a user can have any of the permissions types independent of one another. Users are able to assign permissions to their projects and models by using the Permissions Manager on the Projects Detail and Model Detail pages. The table contains all users on the same account as the user.

[screenshot]

Another way to assign permissions to users that do not belong to the current user's account is by giving them a Permissions Token via the Project Sharing page. By inputting a username and the desired permissions level, then clicking the Share button, a unique Token will be generated for the specified user.

[screenshot]

The other user can then input the generated token to gain access to that project or model.

[screenshot]

This user, along with any other external users, will appear in the Permissions Manager under a separate External Users table.

[screenshot]

== Read permissions ==
'''If a user has Read permissions, they have the most basic access to a project or model.'''

The user is allowed to switch to a project to which they have Read permissions to all the contained models. The user is allowed to see all the content of their Read access projects and models. The user is also allowed to export their project for use elsewhere. In addition, if the model inherits from another model, a user with Read permissions is allowed to see the nodes that can be pulled from a parent model, but are prevented from actually pulling that content. Likewise, if a model has other models that inherit from it, a user with Read permissions to the model is allowed to see the push requests from the children models, but is not allowed to approve those changes.

Read permissions are also unique from the other permissions types because in order to have any other permissions, a user is required to also have Read access, to prevent scenarios where a user is allowed to edit model content that they are not even allowed to see. This is why a user wanting to assign Write or Admin permissions are not allowed to disable Read permissions, as seen below.

[screenshot]

== Write Permissions ==
'''If a user has Write permissions, they are allowed to edit project and model content.'''

The user is able to modify fields on the details pages of nodes in the model, as well as the majority of the actions related to inheriting models. If the model inherits from another model, the user with Write access is able to request to push content to the parent model. Assuming that the user also has Read permissions to the parent model, the user is also allowed to pull any new changes from the parent model. Likewise, if a model has other models that inherit from it, a user with Write permissions to the model is allowed to approve content changes and delete push requests.

== Admin Permissions ==
'''If a user has Admin permissions, they are allowed to make changes to projects and models themselves.'''

A user who has Admin access to projects or models is allowed to change the permissions of the projects or models to users who belong to the same account as them. A user with Admin access to a model is also allowed to create inheriting models from it.

== Owner Permissions ==
'''If a user has Owner permissions (or "owns" a project or model), they were the creator of the project or model, and therefore have all of the above permissions types, as well as some more actions limited to just the owner of the project or model.'''

A user that owns a project or model is allowed to change permissions, both to users that belong to the same account as them, as well as external users, sharing permissions with them via Permissions Tokens. If a user owns a project and wishes to give other users permissions to it that are higher than those users currently have, the user must also have Admin permissions to all the contained models. In addition, the Owner of a project or model is the only user allowed to rename or delete the projects and models they own. If a user owns a project or model, no other user is allowed to revoke any of their permissions.

It should be noted that if a project or model was created before April 2nd, 2024, the project or model may have more than one Owner. When Owner permissions were added, the Owner of a given project or model was determined to be anyone who had Admin permissions to that project or model, excluding any user who recieved Admin access via a Permissions Token. All projects and models created after April 2nd, 2024, only have one Owner.

== Account Admins ==
Account admins are able to see all the projects and models that exist on their account, and are able to assign permissions to those projects and models to any user on the same account. In the case that a project or model was shared to someone on an account using a Permissions Token, that account's Admins are only allowed to assign permissions to the project or model that someone on the account holds.

Permissions

2024-04-02T16:46:57Z

Josh: Added permissions page detailing everything needed to know about new permissions regime

== General ==
Permissions are a user's access level to either a project or a model. There are four different types of permissions, and a user can have any of the permissions types independent of one another. Users are able to assign permissions to their projects and models by using the Permissions Manager on the Projects Detail and Model Detail pages. The table contains all users on the same account as the user.

[screenshot]

Another way to assign permissions to users that do not belong to the current user's account is by giving them a Permissions Token via the Project Sharing page. By inputting a username and the desired permissions level, then clicking the Share button, a unique Token will be generated for the specified user.

[screenshot]

The other user can then input the generated token to gain access to that project or model.

[screenshot]

This user, along with any other external users, will appear in the Permissions Manager under a separate External Users table.

[screenshot]

== Read permissions ==

===== If a user has Read permissions, they have the most basic access to a project or model. =====
The user is allowed to switch to a project to which they have Read permissions to all the contained models. The user is allowed to see all the content of their Read access projects and models. The user is also allowed to export their project for use elsewhere. In addition, if the model inherits from another model, a user with Read permissions is allowed to see the nodes that can be pulled from a parent model, but are prevented from actually pulling that content. Likewise, if a model has other models that inherit from it, a user with Read permissions to the model is allowed to see the push requests from the children models, but is not allowed to approve those changes.

Read permissions are also unique from the other permissions types because in order to have any other permissions, a user is required to also have Read access, to prevent scenarios where a user is allowed to edit model content that they are not even allowed to see. This is why a user wanting to assign Write or Admin permissions are not allowed to disable Read permissions, as seen below.

[screenshot]

== Write Permissions ==

===== If a user has Write permissions, they are allowed to edit project and model content. =====
The user is able to modify fields on the details pages of nodes in the model, as well as the majority of the actions related to inheriting models. If the model inherits from another model, the user with Write access is able to request to push content to the parent model. Assuming that the user also has Read permissions to the parent model, the user is also allowed to pull any new changes from the parent model. Likewise, if a model has other models that inherit from it, a user with Write permissions to the model is allowed to approve content changes and delete push requests.

== Admin Permissions ==

===== If a user has Admin permissions, they are allowed to make changes to projects and models themselves. =====
A user who has Admin access to projects or models is allowed to change the permissions of the projects or models to users who belong to the same account as them. A user with Admin access to a model is also allowed to create inheriting models from it.

== Owner Permissions ==

===== If a user has Owner permissions (or "owns" a project or model), they were the creator of the project or model, and therefore have all of the above permissions types, as well as some more actions limited to just the owner of the project or model. =====
A user that owns a project or model is allowed to change permissions, both to users that belong to the same account as them, as well as external users, sharing permissions with them via Permissions Tokens. If a user owns a project and wishes to give other users permissions to it that are higher than those users currently have, the user must also have Admin permissions to all the contained models. In addition, the Owner of a project or model is the only user allowed to rename or delete the projects and models they own. If a user owns a project or model, no other user is allowed to revoke any of their permissions.

It should be noted that if a project or model was created before April 2nd, 2024, the project or model may have more than one Owner. When Owner permissions were added, the Owner of a given project or model was determined to be anyone who had Admin permissions to that project or model, excluding any user who recieved Admin access via a Permissions Token. All projects and models created after April 2nd, 2024, only have one Owner.

== Account Admins ==
Account admins are able to see all the projects and models that exist on their account, and are able to assign permissions to those projects and models to any user on the same account. In the case that a project or model was shared to someone on an account using a Permissions Token, that account's Admins are only allowed to assign permissions to the project or model that someone on the account holds.

Manage Models

2024-04-02T14:48:35Z

Josh: Added link to a permissions page which does not exist yet.

==[[Projects and Models Management]]==

==[[Push, Pull, and Approve Process]]==
Within Manage, the Branch tab is where users manage branching, including the ability to switch branches, pull changes from the parent branch, request to push changes to the parent branch, and approve push requests.

==[[Creating a Filtered Project]]==
In some instances, a user may wish to share only a small part of a project with another user, without burdening them with the entirety of it. If the user you are sharing with only needs access to a few views or a subset of the measurements available, this functionality can be utilized to build a new filtered project that maintains its model inheritance relationship with the initial project. Any changes made to this new project can be pushed up to the initial project, and any changes made in the initial project can be pulled down to the filtered project so long as the changes are to a non-filtered element.

==[[Changesets]]==
Within Manage, the Change Sets tab is where users can create or view a change set and its contents.

== [[Permissions]] ==
Permissions allow users to control who can see and edit project and model content.

Projects and Models Management

2024-03-29T16:18:22Z

Josh: /* Projects Management */ Update to be accurate to new permissions regime

== Projects & Models 101 ==
A '''project''' in PHENOM is composed of one or more models which are loaded together into a workspace.
A '''model''' is a collection of nodes. A node can be an entity, an association, an observable, a view…
One objective of a project is to be:
* Independent
* Complete: reflect the reality to the best of its ability
* Compliant
* Valid (or at least "validatable ")
A model in and of itself might not constitute a complete, compliant, or even valid project as it might depend on entities inside other models, making it impossible to load independently. However, by combining several models in a project, they can form a complete, compliant, and valid model.

[[File:Phenom-manage-project model structure1.png|600px|border]]

The following diagram depicts how a model can be part of multiple projects.

[[File:Phenom-manage-project model structure2.png|600px|border]]

Once a project is loaded into PHENOM, the node contents of its constituent models can be added to as well as edited.

== Projects Management ==
When in PHENOM > Manage Models > Projects, the user can see the projects and models he has access to.

[[File:Phenom-manage-projects models list.png|500px|border]]

The project you are currently working on is displayed at the top of all the pages. Additionally, in the Manage Projects page, the active project is the expanded by default and has a different icon.

[[File:Phenom-manage-active project.png|600px|border]]

To create a project, the user can click on the + button in the Projects list and then select existing models, import new FACE models, or add new blank models.

[[File:Phenom-manage-new project.png|600px|border]]

There are three ways a user can have access to a project or a model:
* He creates it
* He uploads it
* Another user gives him permission to it
The user will see, for each model, its inheritors and versions.

The user can easily switch between projects in the Projects Management page.

[[File:Phenom-manage-switch project.png|800px|border]]

== Model Versions ==
In PHENOM, models maintain the content as well as the record of changes made to that content.

By default, each model has a "live" version. This is the version of the model which, when loaded in a project can be edited and amended.

When the user is satisfied with the current state of a model, he can publish it, thus creating a “static” version of that model. A published version of a model is a snapshot of its content at one point in time. It cannot be added to or edited but can still be included in a project, referenced by and depended upon by the contents of a different model.

In the example below, the model version FACE_SDM_306 and FACE_SDM_316 are a "published" version of the FACE_SDM model. While it can be shared with other users, included in a project, and referred to and depended upon by other models, it can never be edited. In the Model tree, all published models have their publication dates displayed for ease of use.

[[File:Phenom-manage-published model.png|600px|border]]

== Model Inheritance & Content Merging ==
The same model can be loaded as a part of several different projects. However, the users of those projects will not be able to edit the content of the model simultaneously.
When a user chooses to include in a project a model which is already a part of a different project, a "child" model will be created. This inheriting or "child" model is not a different version of a model, but rather its own model which inherits some portion of its content.
At first, the inheriting and the parent models are identical but as their respective user make changes, they grow apart. Therefore, it’s possible for this "child" model to merge its changes to and from the parent model.
A user can see the relationships between models in Manage Models > Projects > Model.
In this example, the model Coffee is the parent of the model Coffee_in_Coffee_2. This results from the Coffee_live version of the Coffee model being loaded into a new project. When edits are made in either the parent or child model, the changes can be merged between them.

[[File:Phenom-manage-model branching.png|600px|border]]

Clicking on a live or published model will display its characteristics on the right panel. The user will be able to edit some of the model's characteristics and the permissions of the model, provided he has Admin privileges for that model.

[[File:Phenom-manage-model details.png|800px|border]]

== Sample Workflow ==
This section goes over a sample workflow which employs the PHENOM project and model structure concepts described in the sections above.
In the scenario laid out below, a group of users, Chris, Dave, Nick, and Riley are working on different parts of completing a data model and documenting a set of interfaces against it. Each of them plays a slightly different role in the process, and they will use some of PHENOM's Model management features to keep their work organized.

=== Part 1 – Chris ===
Chris is working on updating the Shared Data Model (SDM) the group is using to conform to the latest changes released in an accepted standard. He loads an SDM content file to create a model.

[[File:Phenom-manage-example chris 1.png|600px|border]]

[[File:Phenom-manage-example chris 2.png|300px|border]]

He loads the model into an SDM_Editor project and begins to make the changes.

[[File:Phenom-manage-example chris 3.png|600px|border]]

[[File:Phenom-manage-example chris 4.png|300px|border]]

Once he has made the changes necessary to match a decided-upon standard, he publishes a version v1 of his SDM model.

[[File:Phenom-manage-example chris 5.png|300px|border]]

[[File:Phenom-manage-example chris 6.png|300px|border]]

Chris is going to make further changes in the SDM_Editor project, but that will be for the next standard update. In the meantime, he wants to make the static version of the SDM he just published available to the rest of his team, so he gives them Read permissions to it. However, making further changes to the SDM is his job and he wants to stay in control of the process, so he does not give any of his colleagues permissions to either the live version of the SDM model or the SDM_Editor project.

[[File:Phenom-manage-example chris 7.png|600px|border]]

=== Part 2 – Dave ===
Dave is working on creating a Domain Specific Data Model (DSDM) for the team to use - he will be referencing the SDM Chris released in his efforts. He creates a new project into which he adds the SDM version he has access to and a blank model which will contain the DSDM content he creates.

[[File:Phenom-manage-example dave 1.png|600px|border]]

After he has added some content to his DSDM model which references nodes in the SDM, he will see that his DSDM model is now listed as dependent on the SDM model he has been using – which means, it can no longer be loaded without it.

[[File:Phenom-manage-example dave 2.png|600px|border]]

[[File:Phenom-manage-example dave 3.png|600px|border|]] Note that the model section at the top right of the page lists DSDM_live as the home of the Engine entity

Nick and Riley will be documenting some interfaces against the domain model that Dave is working on. However, Dave does not want them to have to wait for him to have finished with all of his work before they can start. Also, as they work on their interface documentation, they may come up with good changes to the DSDM and suggest that they be included in Dave's work. So, Dave decided to share his project with Nick and Riley, giving them Read/Write permissions, which automatically gives them permissions to the active DSDM model version he's working on.

[[File:Phenom-manage-example dave 4.png|600px|border]]

=== Part 3 – Nick & Riley ===
Nick and Riley will be documenting interfaces using the DSDM that was shared with them, but they will be working with different sets of interfaces, each in his own project.
If they try to create a new project with just the DSDM, they will be rejected because they must also load in the SDM that was used to create it and on which it depends.

[[File:Phenom-manage-example nick riley 1.png|600px|border]]

Once they have the appropriate permissions to all of the content, they can create their individual project with the models to house their documentation work separate from the contents of both the SDM and the DSDM.
In the example below, Riley creates a RILEY_s_INTFC_DOC project including the DSDM_live model and a new blank model for his changes. By doing so, a new model, DSDM_IN_RILEY_S_INTFC_DOC, was created, inheriting from Dave’s DSDM_live.

[[File:Phenom-manage-example nick riley 2.png|600px|border]]

Dave and Riley will now be able to independently edit DSDM content and merge changes between their two models as they see appropriate.
Whenever Dave makes new updates to the DSDM, Nick and Riley have the opportunity to pull in those changes into their copies of the model. When either one of them makes a change to the DSDM portion of his project that he thinks should be included in the official version, they can make a push request to Dave's project that he can then either approve or ignore.