In role-based authority management, "user" and "data" are not directly linked.In the meantime we will introduce the concept of "authority".
Wagby provides role-based authority management functions.
The basic unit of authority is called "permission".
For example, there are "display permission of customer model" and "update permission of employee model".
Each screen has a check function "You need XXX authority for this model to process yourself." Each part of "XXX" contains basic authority such as "registration" "update" "delete" "display" "search".
A group of multiple permissions is called a "principal".For example, you can group "registration" "update" permissions and prepare "update principals".Wagby's standard is "multiple permissions = 1 principal".
Wagby has the following principals as standard.
|Common processing||You can specify preferences (color scheme and display control of each part).|
|Change Password||You can change the password.|
|System Administrator||I have all the authority.It is assigned to the account "admin" prepared by the standard.|
|General user||View/Search/Update/Register/Delete/Download/Upload/Menu/List Update/Form Output
"Menu" means authority displayed on the menu.
|Group administrator||For each group, you can prepare a "group manager" with special authority for the data in the group.|
|Group administrator (proxy registration not allowed)||Data can be operated with the authority of the group administrator, but proxy registration can not be done.|
|Holidays setting updater||You can add "holiday" managed by the system.|
|Account viewer||You can view account information other than yourself.Proxy registration function with group authority settingAndProxy approval of workflowI will use it.|
|Flow status browsing||In the workflow,Confirm workflow to approveSometimes,Check the state of the applied workflowIt is authority for.|
|Workflow agent setting||Proxy approval of workflowI will use it.|
|Mail template administrator||"mail template"Can be registered and updated operations can be performed.|
|Form definition administrator||"Form template"Can be registered and updated operations can be performed.|
|Notification manager||You can register and update "Notification".|
|Job administrator||You can register and update "job master" provided by Wagby.|
|Job Schedule Manager||You can define the execution rule of "job" provided by Wagby.The job starts at the specified time.|
|Batch job management||It is the authority to operate the state of each batch job by batch processing using Spring Batch.In the initial setting, since the update function is disabled, it can not be used even if this permission is set.(In principle, viewing only batch jobs are allowed.)|
|Batch job browsing||You can view the state (instance, execution result, step) of each batch job by batch processing using Spring Batch.|
|Workflow administrator||Flow pattern,Flow Participant Setting,Workflow settingThe authority to do.|
|Master updater||"Option modelThis is the right to perform the operation.|
|Job dedicated account||Special authority to be able to execute jobsis.|
|Disconnect||It is a privilege that can only forcefully cancel a logged on user.For details, refer to "Administrator Guide> Logon user managementPlease read.|
The Wagby logon account is defined as the juser model. When setting up the logon account, you can specify which principals to assign.
"Permission" can be set for each model item instead of screen unit.
This makes it possible to make the following complicated settings as well.
The authority setting is applied to "screen" "form" "CSV/Excel download/upload update".
General users will be covered.The system administrator (admin) will have all permissions enabled.
The "system administrator" principal operates as follows.
The following manual explains how to add a principal.The added principal is stored in the table "jprincipal" prepared in the database.Normally, this model can not be operated from outside, but it exists as table information.When importing/exporting account information (juser), jprincipal is also operated.
The primary key (principal ID) of jprincipal is automatically assigned at the timing of the build.(The sort order is "Principal name (English)".)
When using an external database, by adding import_db.bat after the build, the added principal is reflected in the application.For details, refer to "Support> Database utilization guide (R7)> Create table"After the second timePlease read the procedure of ".
"Assign principal to logon accountAs you can see, you can associate multiple principals with your account.Internally juser maintains multiple principal IDs.
In this way, juser refers to the ID value of jprincipal, but when jprincipal is newly added, since the ID value of jprincipal gets down again despite the fact that the ID value held by juser is unchanged, "Misalignment" will occur.
Even when the principal ID changes due to addition or deletion of a principal, consistency is maintained by performing normal application replacement rules (export and import processing).
From this mechanism, when adding or deleting a principal, it is reflected by importing the account model (juser).Specifically, it becomes the following operation.
The added principal is automatically reflected at the timing of 3.