The Constellation server is used by different participants, either in Modelio or in a Web browser. These participants can be put into two main categories:
The case of users is straightforward, as users can only access projects that they are a part of. Everything happens as if they had only one role, that of a user.
The case of administrators, who can modify the configuration of projects and the teams in charge of these projects, requires that more care be taken. This is why Constellation identifies four possible roles for an administratot, with each role defining exactly which functions and configuration operations are possible and authorized.
The four possible administrator roles are summarized in the table below:
| Role | Access | Description |
|---|---|---|
| Project administrator | Web browser | A project administrator is in charge of configuring one or several projects. |
| Domain administrator | Web browser | A domain administrator is in charge of a domain containing a set of projects. |
| Domain server administrator | Web browser | A domain server administrator has a similar role to that of a server administrator (see below), but limited to the scope of one particular domain. |
| Server administrator | Web browser | The server administrator can potentially carry out administration operations on any object managed in Constellation, even if in practice he/she does not necessarily have this responsibility within the organization. The server administrator is the person to go to if difficulties arise (absence of another administrator, technical problems, and so on.) |
| User | Modelio | Standard Modelio user, who can access the projects that he/she is a member of via Modelio, as well as these projects' portals. |
Note: The user pseudo-role has been included in the table, even though the user is not strictly speaking an administrator role. It corresponds to a non-administrator user who logs onto the server administration pages via a Web browser. This non-administrator user will then access a pages which is limited to the consultation of the projects he/she is a member of, with no possibility of carrying out operations on these projects.
An administrator has administration rights, which enable and authorize him/her to carry out certain operations or to use certain functions in Constellation. These administration rights are directly linked to the user’s role, and can be configured in accordance with the rights granted by the role. The different roles are linked to the nature of the objects managed in Constellation, mainly projects, domains and the server itself. Because roles are specialized by category of object managed, certain conditions must be respected, in order to benefit from administration rights on these objects. For example, you must be a member of a project before you can carry out administration operations on it, and you must be a member of a domain before you can manage it. Membership of a project or domain is called enrolment in the project or the domain.
The table below summarizes the organization of the roles and enrolments required in Constellation.
| Role | Required enrolment | Object categories managed |
|---|
Project administrator | Project |Project (management), members of a project Domain administrator | Domain |Domain, members of the domain, projects of the domain (creation) Domain server administrator | Domain |All objects within the scope of the domain Server administrator | |All objects within the scope of the server (trans-domain)
Example: In order for John to become administrator of a project, he must already be enrolled as a member of the project. His project administrator rights can then be precisely configured, in order to specify which operations and services he will be able to use on the project.
When a role is allocated to a user, the exact list of administration rights is then established, by configuring the theoretical rights granted by the role. Each role grants a certain number of basic rights, and each basic right can then be configured for each user to whom the role in question is allocated. The enables a user’s role to be further defined. It is possible, for example, to allocate to a user a server administrator role, which is limited to certain functions. The user in question becomes a sort of “secondary” server administrator.
Most basic rights associated with a role are of boolean type, meaning they can take one of two possible values :
However, some basic rights, notably for server administration roles, can take one of three possible values:
The RESERVED value is used to indicate that the operations and services associated with the right are not normally the responsibility of the current user, but that the operation is possible on an exceptional basis. The user is asked to confirm the operation, so that he/she is fully aware that he/she is acting on an exceptional basis, and that he/she accepts responsibility.
Example: A project team urgently needs to modify the configuration of its project, by adding an additional member to the team. In the absence of a Project Administrator, this team is paralyzed. The teams therefore contacts the server administrator to ask him/her to reconfigure the project. However, the server administrator is currently a company system administrator whose job does not include constituting project teams within the company. He/She is not supposed to carry out this change within the organization.
Here, the RESERVED value will be used for the corresponding right, to indicate that even though the server administrator is not supposed to carry out this operation, he does have the possibility to do so.
If we had used the REFUSED value, the team would have been blocked until the return of the project administrator.
If we had used GRANTED, we would have weakened the organization, through a poor definition of each person’s responsibilities.
The rights associated with each role are described here:
Project administrator rights
Domain administrator rights
Domain server administrator rights
Server administrator rights