[Equanda-svn-commit] SF.net SVN: equanda: [343] trunk/equanda-generate/src/site/wiki/templates/ t5guiAuthorization.wiki

[<tri...@us...>]

Revision: 343
          http://equanda.svn.sourceforge.net/equanda/?rev=343&view=rev
Author:   triathlon98
Date:     2008-02-25 04:47:25 -0800 (Mon, 25 Feb 2008)

Log Message:
-----------
authorization docs

Added Paths:
-----------
    trunk/equanda-generate/src/site/wiki/templates/t5guiAuthorization.wiki

Copied: trunk/equanda-generate/src/site/wiki/templates/t5guiAuthorization.wiki (from rev 342, trunk/equanda-generate/src/site/wiki/templates/t5guiRights.wiki)
===================================================================
--- trunk/equanda-generate/src/site/wiki/templates/t5guiAuthorization.wiki	                        (rev 0)
+++ trunk/equanda-generate/src/site/wiki/templates/t5guiAuthorization.wiki	2008-02-25 12:47:25 UTC (rev 343)
@@ -0,0 +1,81 @@
+h1. equanda rights handling
+
+The equanda generated user interface should be very flexible.
+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.
+
+h2. 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
+
+
+h3. 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.
+
+
+h2. 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
+
+
+h2. How to combine
+
+- 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.
+- Check whether personal choice has not overwritten the result.
+
+
+h2. Implementation
+
+The equanda-generate module src/main/resources/org/equanda/infrastructure/usersadmin directory currently contains the table structure for the user administration fields. These were applicable for the tapestry4 version of the useradmin stuff.
+I think this should be modified. The "preferences" fields in "EquandaUser" and the "EquandaRight" tables could be removed and replaced by a CLOB field which contains the rights as properties file.
+When reading these, the could be put in a hashtable which can easily be cached and combined.
+
+A tapestry service for handling the authorization would be needed. This would handle all the details for a specific user and language, getting the data from the database (in principle through the cache, but it is easier not to implement this immediately).
+This service can then be injected in pages which need this functionality. It should contain methods for each of the authorization rights, like "getTableFieldRights("Company.Address")".
+
+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.
\ No newline at end of file


This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site.