Difference between revisions of "Authorization DSL"

Latest revision as of 10:32, 2 December 2019

Introduction

AuthorizationDSL is used to authorize the roles at runtime. For example, when the sales and logistics check the same entity of article, the sales do not need to know how many cases per pallet for an article, so it should be invisible in vision of the sales; the logistics do not need to know how much costs the article, so in vision of the logistics, the price should not be displayed.

AuthorizationDSL

The AuthorizationDSL is working at runtime. It's used to define the roles and authorize them. Visibility processor at runtime calculates the authorization of e.g. invisible or editable for the roles; Blips are working for the bpm process at runtime, e.g. starting the user task.

There will be no exported file generated after editing the model. The authorization rules will be store in a hash map at runtime. Each user should have its own position, and the role will be assigned to the positions in Organization DSL, which is also working at runtime.

The authorization at runtime will be done according to the rules which we defined in AuthorizationDSL.

The main semantic elements of the AuthorizationDSL are:

• “package” - the root element that contains all the other elements. A model can contain multiple packages.

• “role” - define the role in the fact, e.g. sales, logistics…It contains further elements such as entity and process.

• "ENTITY” - define which entity should be authorized, and how to authorize it for the roles, the entity is defined in Entity DSL model.

• "BEAN” - define which bean should be authorized, and how to authorize it for the roles, the bean is defined in Entity DSL model.

• "DTO” - define which DTO should be authorized, and how to authorize it for the roles, the DTO is defined in DTO DSL model.

• “attribute” - define the authorization of the entity/bean/DTO attributes for the roles.

• “relation” - define the authorization of the referenced entity/bean/DTO for the roles.

• “PROCESS” - define which process is STARTABLE and if the user task of this process is TASKABLE for the roles. The process is defined in Bilp DSL model.

• “TASK” - define which user task is TASKABLE for the roles.

Syntax

package definition

► Syntax:

package <package name>  {
    role <role name> {...}
    ...
}

The package definition of AuthorizationDSL is just like most of the DSL models, you just need to define the package name and in eclipse like other java project press ctrl+shift+o, all necessary models or java classes will be imported automatically. After that, you can define the roles and their authorization rules. One or more roles can be defined in the same package.

► Example:

package org.eclipse.osbp.foodmart.authorizations {
	import org.eclipse.osbp.foodmart.entities.* 
	import org.eclipse.osbp.foodmart.blips.*
	. . .
	role Sales {. . .}
	. . .
}

role

This is the main part of this model. Either entity or process could be authorized in this part.

► Syntax:

role <role name> {
    ENTITY <entity name> ... [{ ... }]
	  ...
  | BEAN <bean name> ... [{ ... }]
	  ...
  | DTO <dto name> ... [{ ... }]
	  ...
  | PROCESS <blip name>{ ... }
  ...
}

► Example:

role Sales {
  ENTITY Mproduct_class ANY
  ENTITY  Memployee ANY {. . .}
  PROCESS ProductMaintenance {. . .}
. . .
}

In this example, the authorization rule for role Sales will be defined. The rules are using to ENTITY Mproduct_class, ENTITY Memployee and PROCESS ProductMaintenance.

ENTITY

You can define the authorization rule for the whole entity or for one or more attribute/reference of this entity.

► Syntax:

ENTITY <entity name> RoleEnum [{   
	attribute <entityAttribute name> INVISIBLE|DISABLED|NONEDITABLE
	relation <entityReference name> INVISIBLE|DISABLED|NONEDITABLE
	...
}]

• RoleEnum is including ANY, CREATABLE, READABLE, UPDATABLE and DELETABLE. It is defined for the whole entity. any means allowed all. Otherwise, only the operation which is listed is allowed, they are CREATABLE, READABLE, UPDATABLE and DELETABLE; it can be one or more operations listed at the same time.

• Entity attribute and reference could be authorized as INVISIBLE, DISABLED and NONEDITABLE. Only the operation which is listed is allowed, it can be one or more operations listed at the same time.

► Example:

ENTITY Mproduct_class ANY

	
ENTITY Memployee ANY{
	attribute first_name INVISIBLE
	relation position NONEDITABLE
}

The following picture is a dialog of ENTITY Memployee, you could see for the role sales, the attribute first_name is not shown, only full_name and last_name is shown; the reference position is not editable.

BEAN

You can define the authorization rule for the bean or for one or more attribute/reference of this bean.

► Syntax:

BEAN <bean name> RoleEnum [{   
	attribute <beanAttribute name> INVISIBLE|DISABLED|NONEDITABLE
	relation <beanReference name> INVISIBLE|DISABLED|NONEDITABLE
	...
}]

• RoleEnum is including ANY, CREATABLE, READABLE, UPDATABLE and DELETABLE. It is defined for the bean. any means allowed all. Otherwise, only the operation which is listed is allowed, they are CREATABLE, READABLE, UPDATABLE and DELETABLE; it can be one or more operations listed at the same time.

• Bean attribute and reference could be authorized as INVISIBLE, DISABLED and NONEDITABLE. Only the operation which is listed is allowed, it can be one or more operations listed at the same time.

► Example:

BEAN Address ANY {
	attribute country INVISIBLE
}

DTO

You can define the authorization rule for the DTO or for one or more attribute/reference of this DTO.

► Syntax:

DTO <dto name> RoleEnum [{   
	attribute <dtoAttribute name> INVISIBLE|DISABLED|NONEDITABLE
	relation <dtoReference name> INVISIBLE|DISABLED|NONEDITABLE
	...
}]

• RoleEnum is including ANY, CREATABLE, READABLE, UPDATABLE and DELETABLE. It is defined for the DTO. any means allowed all. Otherwise, only the operation which is listed is allowed, they are CREATABLE, READABLE, UPDATABLE and DELETABLE; it can be one or more operations listed at the same time.

• DTO attribute and reference could be authorized as INVISIBLE, DISABLED and NONEDITABLE. Only the operation which is listed is allowed, it can be one or more operations listed at the same time.

PROCESS

The process and the user task in this process could be authorized in this part.

► Syntax:

PROCESS <blip name>{ 
	[is STARTABLE]
	[all usertasks TASKABLE]
	TASK <blipTask name|Task name> TASKABLE
	...
}

• is STARTABLE means: this process is allowed to be started.
• all usertasks TASKABLE means: all user tasks of this process are allowed to be executed.
• If not all the user tasks are allowed to be executed, you can define here which user task is allowed to be executed using keyword TASK … TASKABLE.

► Example:

PROCESS ProductMaintenance {
	is STARTABLE
	all usertasks TASKABLE
}

Copyright Notice

All rights are reserved by Compex Systemhaus GmbH. In particular, duplications, translations, microfilming, saving and processing in electronic systems are protected by copyright. Use of this manual is only authorized with the permission of Compex Systemhaus GmbH. Infringements of the law shall be punished in accordance with civil and penal laws. We have taken utmost care in putting together texts and images. Nevertheless, the possibility of errors cannot be completely ruled out. The Figures and information in this manual are only given as approximations unless expressly indicated as binding. Amendments to the manual due to amendments to the standard software remain reserved. Please note that the latest amendments to the manual can be accessed through our helpdesk at any time. The contractually agreed regulations of the licensing and maintenance of the standard software shall apply with regard to liability for any errors in the documentation. Guarantees, particularly guarantees of quality or durability can only be assumed for the manual insofar as its quality or durability are expressly stipulated as guaranteed. If you would like to make a suggestion, the Compex Team would be very pleased to hear from you.

(c) 2016-2024 Compex Systemhaus GmbH