equanda rights handling

*Note :* to assure the authorization and configuration work, you have to configure your login to work properly.

The equanda generated user interface should be very flexible and extremely configurable, both for the user and for an administrator who can define what is allowed by a user.

The administrator for the application (gui administrator) can determine which roles users can have and for each role, he/she can determine which pages, which tables, which fields etc are allowed to be seen, used and modified.

This is a layered approach where some defaults are defined in the domain model, restrictions can be defined by an administrator (based on roles) and the user herself can also choose whether they want certain information to be hidden.

The EquandaUser table is used to indentify the logged in user. This user can be part of one or more roles and have some personalizations.

Some users can have the administration rights (this is a field in the EquandaUser table).

In this documents, we mention three types of rights : "no", "view" and "edit". The "edit" rights imply "view". "No" means that whether or not data exists is not even allowed to be known to the user.

Role based configurable aspects

For each table

• whether the user has view/edit/no rights on the table. Default is "edit".

• If the user has edit rights :

• whether the user is also allowed to delete records

• whether the user is allowed to invoke any actions

• whether the user is allowed to create new records

• default selector (this itself defaults to the "equandaAll" selector)

For each field (if the user has view or edit rights on the table)

• whether the user has view/edit/no access rights on the field (never more than globally for the table)

• whether the field should be displayed in select lists

• whether the field should be included in printed lists

• whether the field should be displayed in table summary display

For each action (if the user has edit rights on the table and is allowed actions)

• whether the action can be invoked by the role

For each builder (if the user has edit rights on the table)

• whether the user is allowed to invoke that builder

For each selector (if the user has view or edit rights on the table)

• whether the user is allowed to use that selector

User definable configurable access in trees

equanda should give some kind of support for building configurable menu trees. Some components should be written for this.
One example use of this is for a menu with the tables which are available in the application.

For the tables, the generation should allow generating a tree with enough annotations to allow the component to have the details (using the "category" attribute to define the structure).

There needs to be a mechanism for registering the trees (to allow the security pages to build access right info for them).
A service should be written which allows obtaining details for a specific tree (for a user and language).
The tree should contain references to the keys which contain the labels and the keys which are used for the rights management.

When obtaining these details, it should be possible to traverse the tree to get the details and all nodes in the tree should be allowed to be viewed. Therre should be two orders to traverse the tree, one being the declared order, the other being alphabetically sorted on the labels.

User based configurable aspects

For each table (if the user has view/edit rights based on their roles)

• whether the user wants this table to be hidden

• default selector

For each field (if the user has view or edit rights on the table based on their roles and want to see the table)

• whether the user wants to see this field

• whether the field should be displayed in select lists

• whether the field should be displayed in table summary display

How to combine

• Check whether personal choice indicates that the data should be hidden.

• For each of the roles for the user, get the specific rights.

• If none found, use the defaults from the domain model.

• If one or more found, use the most permissable.

Implementation

Some kind of interface to get the authorization and configuration information for a user should be created. This AuthAndConfigProvider class in provided for this.
The actual information is read from the AuthAndConfig fields in the EquandaUser and EquandaRole tables. These are processed as part of the login in the application. A login filter is provided which assures the information is cached, the cached information is then made available as part of a tapestry service.
Some binding prefixes are provided for easy access to the authorization and configuration details. These binding prefixes are called "equanda-readable", "equanda-writable", "equanda-summary", "equanda-list" and "equanda-print".

The information stored in the AuthAndConfig is parsed by the AuthAndConfigProvider. Each line contains a key-value pair.
Keys have the following structure

• table.TableName

• field.TableName.FieldName

• action.TableName.ActionName

• build.TableName.BuildName

• select.TableName.SelectName

Values are a combination of letters, each having a meaning

• R : readable

• W : writable, should be combined with readable

• D : delete, should be combined with readable and writable

• H : hidden, overwrites both read and write

• S : display in table summaries, should be combined with readable

• L : display on (on-screen) lists, should be combined with readable

• P : display in printed lists, should be combined with readable

The templates need some "t:if" components to wrap the content to assure the authorization is adhered to. For example the "field.tml.vm" template can handle whether a field is visible or not. It should be handled for the individual fields in the edit forms and also for the columns in the grid which is displayed by the select component).

Some pages are needed for managing the rights. There should be a set of pages (with a start page) for an administrator (managing the roles), and a set of pages for the user herself (allowing the hiding of fields and managing the list fields).
These pages can probably be fixed but reading the configuration from a (set of) generated config files.

Authorization Pages

The page used for managing the roles is named AuthAndConfigRoles. To use this page, the user must be a member of a role which has GUI Administrator rights. The list of available roles are provided in a drop-down box, if no roles are selected, the current users rights will be selected for editing.

The page used for managing tables is named AuthAndConfigTables. If the user has admin rights, they are allowed to select what tables are Readable, Writable, and have Delete enabled for each role. Otherwise, the user can set individual tables visible or not.
The user can also choose to Configure the rights for individual tables, with the Configure link.

The page used for managing a table is available by clicking the Configure link in the AuthAndConfigTables page. This link will only be available if the user has read rights on the table to be edited.
The table page allows the rights to be set at a field level. If there are Selectors or Actions available for this table, they can be enabled/disabled here. Each of the Selectors for a table are grouped under the name Selects. Each of the Actions for a table are grouped under the name Actions. All other fields are grouped by Page name or Group name.
Some rights are implicitly enabled when another right is selected. For example, to use enable Print on a field, Read / Visible must also be enabled. To ensure the rights are consistent, the appropriate checkboxes will be enabled or disabled automatically.

It is suggested that the following values be used for the div selectors used in this page.

div.nameCol { position:absolute; left: 10px;  }
div.readCol { position:absolute; left: 250px; }
div.writeCol { position:absolute; left: 300px;  }
div.listCol { position:absolute; left: 350px;  }
div.summaryCol { position:absolute; left: 400px; }
div.printCol { position:absolute; left: 500px; }