Permissions

Copyright 2008-2012 ManyDesigns srl. All rights reserved.

Purpose

Permissions allow the modeler to specify who can do what on the system. Permissions define what users are allowed to create, read, update and delete the various objects. Permissions can go to a fine level of granularity, allowing you to specify read/write rights at the level of individual attributes.

Defining the actors

An actor is an abstraction of a user for two reasons. First, an actor is not one specific user but possibly many, similar users. Second, an actor expresses the role or responsibility in regard to manipulating a class of objects.

Each class in ManyDesigns Portofino has its own actors. To define them, go upstairs and navigate to the class' details page. Find the Permissions button and click on it: you will be presented with the permissions page.

Click on the Add actors button. Here you will see a list of possible actors. This will contain a list of group actors followed by a list of path actors. Read the two subsections below to see what these are. Select/unselect the actors according to your needs. Finally click on Save.

You can return to the actors page any time you want to refine your selection.

Group actors

A group actor is simply any user who belongs to a certain user group. All the groups you have defined on the system are offered as possible actors. Generally, at least Users and User Administrators will appear in this list.

Path actors

A path actor is given by any path that connects the class for which you are defining permissions (let's call it ClassA) to the class User. A path can be a simple relationship between ClassA and User, or it can be a concatenation of relationships: e.g. ClassA related to ClassB, which in turn is related to User. Paths can be of any length between one and nine relationships.

Portofino automatically examines the model to find paths between your class and the cass User. It presents the paths it has found using the following formalism:

• DownRelSegment("Class", "RelAttr"): starting form Class, follow its relationship attribute RelAttr.
• UpRelSegment("Class", "RelAttr"): starting from Class, follow the relationship attribute RelAttr that has Class as its opposite end class.

This formalism can be made recursive to define paths of greater length. For instance:

DownRelSegment(DownRelSegment("Class", "RelAttrA"), "RelAttrB")

is the path obtained by starting from Class, following RelAttrA, then following RelAttrB.  

The permissions matrix

After you have defined a class' actors, the following table appears in the class' permission page.

The table is structured as follows.
On the rows, there are three section:

• Operations: create and delete.
• Attributes: all the class' attributes are listed.
• Transitions: all the class' transitions are listed, if the class has a workflow.

On the columns, there is one column for each actor you have defined. For simplicity actors are referenced by incremental codes such as A1, A2, A3, etc.

At the intersection of the rows with the colums are the actual permissions you can set.
For operations (create and delete) check the checkbox to grant, uncheck it to deny the permission.
For attributes you have a triple choice:

• "-" to deny all permissions
• "r" to grant the read permission only
• "w" to grant both read and write permissions.

When you have finished, click on Save to apply the new permissions.

Previous: User management

Next: Workflows