Accéder au contenu principal
Version: 15.0

Impact of Restricting Access to Metamodel Elements

Based on examples, this chapter illustrates how changing metamodel rights affects working with the ADOIT web client.

Remarque

For information on how to change basic or detailed metamodel rights, please refer to the section Edit Metamodel Rights.

Scenario 1: Creating Models/Objects

Creating models/objects requires permissions to create models/objects of this type and write permissions to the Name attribute.

Example

Edit the basic metamodel rights of the system role "Participant" to the model type Cross-Domain Model:

  • Set the permissions to the Name attribute to Read.

    Now users with the system role "Participant" cannot create Cross-Domain Models.

    You can achieve the same result by editing the detailed metamodel rights of the system role to the model type and setting "Create models" to denied.

Scenario 2: Editing Models/Objects

Editing models/objects requires permissions to edit models/objects of this type.

Example

Edit the detailed metamodel rights of the system role "Participant" to the class Service:

  • Set "Edit objects" to denied.

    Now users with the system role "Participant" cannot edit or rename Services.

Scenario 3: Adding Objects to a Model

Creating objects in a model requires permissions to create objects of this type.

Example

Edit the detailed metamodel rights of the system role "Participant" to the class Risk:

  • Set "Create objects" to denied.

    Now users with the system role "Participant" cannot create new Risks. They can still re-use Risks from the Object Catalogue in models.

Scenario 4: Saving a Copy of a Model

Saving a copy of a model requires permissions to create all the modelling object and relation types which the model contains.

Example

Edit the detailed metamodel rights of the system role "Participant" to the class Note:

  • Set "Create objects" to denied.

    Now users with the system role "Participant" cannot create new Notes. They cannot save a copy of a model that contains a Note.

Scenario 5: Deleting Objects

Deleting objects requires permissions to delete objects of this type.

Example

Edit the detailed metamodel rights of the system role "Participant" to the class Note:

  • Set "Delete objects" to denied.

    Now users with the system role "Participant" cannot delete Notes. They cannot delete a model that contains a Note.

Scenario 6: Opening a Model that Contains Unavailable Objects

Accessing an object in a model requires permissions to read objects of this type:

Example

Edit the basic metamodel rights of the system role "Participant" to the class Risk:

  • Set the permissions to No access.

    Now Risks are not available for users with the system role "Participant". When they open a model that contains a Risk, the Risk is invisible for them.

Scenario 7: Deleting a Model

Deleting a model requires permissions to delete models of this type.

Example

Edit the detailed metamodel rights of the system role "Participant" to the model type Cross-Domain Models:

  • Set "Delete models" to denied.

    Now users with the system role "Participant" cannot delete Cross-Domain Models.

Overview of Permissions to Individual Functions

What permissions are required for the different tasks that can be performed in ADOIT?

Dashboards (Web Client Scenarios)

  • Widgets are empty if none of the displayed object types are available.

  • Columns in a widget are empty if the displayed attribute is not available.

  • Charts are only available if the queried object types/attributes are available.

Model Time Filter

  • The Model Time Filter is only available if the object types for which the filter is configured are available.

Quick Links

  • Links are removed or disabled based on metamodel rights.

Organisation Portal

  • The Organisation Portal is only available if the configured model types and State attribute are available.

Reporting Board

  • Individual Reports are only available if the respective view or report is available.

Reports

  • Model reports and object reports omit attributes that are not available.

  • Application Overview reports are only available if Applications is available.

  • Service Overview reports are only available if Services is available.

  • Demand List reports are only available if Applications or Services and all attributes in the Demands table are available.

Validation

  • A check is only available if the required object types, relations, model types or attributes are available.

Charts

  • Matrix charts are only available if there is at least one available object type/relation for the row/column/cell.

  • Bubble charts are only available if the configured object type and the x-axis/y-axis attributes are available.

  • Gantt charts are only available if the configured object type and the attributes are available.

  • The dependency modeller is only available if Architecture Diagrams or Analysis Models are available. When an analysis is performed with the dependency modeller, layers which contain unavailable object types are empty.

  • Box-in-box charts are only available if the configured object types, relations and the model type are available.