Skip to main content

Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.

Jump to: navigation, search

Scout/HowTo/3.7/Create Permissions

The Scout documentation has been moved to https://eclipsescout.github.io/.

Permissions are needed to control:

  1. Who is allowed to do what action
  2. Who is allowed to see which records

Permission to do certain actions

To enforce that not everybody can do everything, permission are created. A permission has a name, e.g. ReadCompanyPermission. The permissions are grouped into roles, e.g. Standard role or Administrator role. Each user is assigned to one or more roles.

Create a permission

To create a permission in Scout, use the menu "New Permission..." on folder Permissions below folder shared. This creates a class that extends BasicHierarchyPermission.

Use permissions (client side)

On a table page, the following methods checks whether the logged in user has the necessary permission and depending on it sets the visibility of the table page to true or false.

 @Override
 public void execInitPage() throws ProcessingException{
   setVisibleGranted(ACCESS.getLevel(new ReadCompanyPermission())>BasicHierarchyPermission.LEVEL_NONE);
 }

Use permissions (server side)

When creating a process service with Scout, permission classes are created with it. For the methods prepareCreate, create, load and store, the following code is added (on the example of a CompanyProcessService):

 public CompanyFormData prepareCreate(CompanyFormData  formData) throws ProcessingException{
   if(!ACCESS.check(new CreateCompanyPermission())){
     throw new VetoException(Texts.get("YouAreNotAuthorizedToRegisterformData"));
   }
   // TODO business logic here
   return formData;
 }
 public CompanyFormData create(CompanyFormData  formData) throws ProcessingException{
   if(!ACCESS.check(new CreateCompanyPermission())){
     throw new VetoException(Texts.get("YouAreNotAuthorizedToRegisterformData"));
   }
   // TODO business logic here
   return formData;
 }
 public CompanyFormData load(CompanyFormData  formData) throws ProcessingException{
   if(!ACCESS.check(new ReadCompanyPermission())){
     throw new VetoException(Texts.get("YouAreNotAuthorizedToRegisterformData"));
   }
   // TODO business logic here
   return formData;
 }
 public CompanyFormData store(CompanyFormData  formData) throws ProcessingException{
   if(!ACCESS.check(new UpdateCompanyPermission())){
     throw new VetoException(Texts.get("YouAreNotAuthorizedToRegisterformData"));
   }
   // TODO business logic here
   return formData;
 }

The ACCESS.check(Permission p) checks, whether the logged in user has the permission p. If not, an exception is thrown, which results in a message box popping up saying that the user is not authorized to do this action.

Assigning permissions when a server session is created

Here's an example of how to load permissions from a database. If your permissions are stored elsewhere, no problem. Just prepare the permissionData matrix as required: First column with the name of the class, second column with a numerical "level".

   Object[][] permissionData=SQL.select(
       "SELECT  P.PERMISSION_NAME, "+
       "        MAX(P.PERMISSION_LEVEL) "+
       "FROM    ORS_USER_ROLE R, ORS_ROLE_PERMISSION P "+
       "WHERE   R.ROLE_UID=P.ROLE_UID "+
       "AND     P.PERMISSION_LEVEL>0 "+
       "AND     R.USER_NR IN( "+
       "        SELECT  S.USER_NR "+
       "        FROM    ORS_USER_SUBSTITUTE S "+
       "        WHERE   S.SUBSTITUTE_NR=:userNr "+
       "        UNION ALL "+
       "        SELECT  TO_NUMBER(:userNr) FROM DUAL) "+
       "GROUP BY P.PERMISSION_NAME"
   );
   
   SERVICES.getService(IAccessControlService.class).
     setPermissions(permissionData, BasicCrmPermission.PERMISSION_PACKAGE_NAME);

In the above example, the BasicCrmPermission.PERMISSION_PACKAGE_NAME is simply "com.bsiag.crm.shared.security." and used to fully qualify the permissions. Obviously that's exactly where the framework will create these permission classes as mentioned above.

Permission to see certain records AKA row-level granting

To control who is allowed to see certain records, this must be implemented directly in the sql statement that selects the data from the database into the application. Records for which the logged in user has no right to see, are not returned by the sql statement. This is only possible if the users, the roles and the permissions are stored in the database.

Back to the top