Importing Guidelines

When you import an Access Control model, the following behaviors are observed:

• Access Control Objects - All Groups and Permissions. Permissions imported into the target system completely replace (overwrite) the existing Permissions definitions in the target system. When importing Groups, aPriori attempts to maintain existing User-Group associations in the target system by updating existing Groups rather than by deleting and recreating them. Any groups in the target system that are not in the Import file are deleted.

• User-Group Associations - Complete overwrite. Importing a User-Group mapping completely replaces the existing User-Group associations in the target system. aPriori ensures that Users and Groups represented in the mapping exist in the target system. If any are found that do not, the import follows the 'log error and continue' model.

Note: A User-Group Association import replaces all existing associations on the target system, with the single exception that the last superuser will never be removed from the target system. Therefore, it is possible for an import to fail if it is started by a superuser on the target system who does not exist in the source system, and who is not the last superuser on the target system. (I.e., the superuser is removed by the import, and the import fails because that user no longer exists in the superuser group.) This also means that the source system can never be a "sub-set" of the target system, since importing it will cause all users not in the sub-set to be removed from their groups.

Importing Access Control Objects

When you import Access Control Objects, aPriori tries to maintain existing User-Group associations by overwriting existing Groups where the full path of the group is the same in the Import artifact and the target system.

For example, assume that a production system has the following configuration. Note that there are three top-level, user-defined groups: France_Region, Germany_Region, and USA_Region:

A new Access Control configuration with a revised group structure has been developed and tested on a QA machine. Now it needs to be migrated to the production system using Export and Import. Note that, among other changes, the two region groups are now sub-groups under a new user-defined "Europe" group.

After exporting the Access Control Object from the QA system and importing it into the production system, the states of the Group objects are:

 The administrators , super_user , all_users and vpe_administrators groups in the production system have the same Permissions and Attributes as they did in the QA system. The members for these groups are unchanged from what they were prior to the import.

 The USA_Region, USA_Region\Project1, and USA_Region\Project2 Groups in the production system have the same Permissions and Attributes as they did in the QA system. The members for these groups are unchanged (they do not match the members from the QA system). In particular for the USA_Region\Project1 group detailed in the screen shots above, this group in the production system after import will:

• have the read_component and update_component Permissions.

• not have the create_component and delete_component Permissions.

• have the Attr2 attribute but not the Attr1 attribute.

• have both jimbob and rrudis as Members.

• The France_Region, France_Region\Project3, Germany_Region, and Germany_Region\Project4 Groups will be deleted from the production system.

• The following new Groups will be created. They will have the Permissions and Attributes that they had in the QA system, and they will have no Members:

• Europe

• Europe\France_Region

• Europe\ France_Region\Project3

• Europe\ Germany_Region

• Europe\ Germany_Region\Project4