Support > Repository > Authentication/Authorization > Overview of authority management

Wagby's authority management uses the concept of "permission" and "principal".

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.

Figure 1 Without Roll
Figure 2 When using roll (Wagby)

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".

Figure 3 Relationship between permissions and principals
Administrators can assign "principals" to users (accounts). Since this operation can be performed during operation, it is possible to flexibly respond to a certain user temporarily by assigning operation authority or deleting it.

Wagby has the following principals as standard.

type Contents
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.Because this principal is dedicated to executing jobs, if you enable this principal, you will not be able to log on from the logon screen.
Disconnect It is a privilege that can only forcefully cancel a logged on user.For details, please read "Administrator Guide> Logon User Management".

The Wagby logon account is defined as the juser model. When setting up the logon account, you can specify which principals to assign.

Figure 4 Principal setting field on the logon account registration screen

"Permission" can be set for each model item instead of screen unit.
This makes it possible to make the following complicated settings as well.

Reference authority - Hide items for unprivileged users
"Boss's comment" item was prepared in the "business daily report" model.Although this item can be viewed and updated by the administrator, sales staff can not see this item.That is, I do not even know that this item exists.
Update permission - make items read-only for unprivileged users
"Quantity ordered" item is prepared for "Sales" model.This item can be viewed/updated by users who have "Order Quantity Update Authority", but if you do not have the same authority, you can browse, but you can not update.


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.

Please do not use system administrator in the operation test of authority management.

The "system administrator" principal operates as follows.

1. This means that you can not allow the system administrator not to display the screen that a user can view.On the other hand, authorization definitions that do not have any principals, including system administrators, are possible.In this case, it becomes a function which no one can operate.

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, please read the "Support> Database Utilization Guide (R7)> Creating Table> Second or Later" procedure.

This procedure is done automatically when using the built-in database (HSQLDB).

Detailed structure

"Assign principal to logon accountAs you can see, you can associate multiple principals with your account.Internally juser maintains multiple principal IDs.

Figure 5 Relationship between juser and jprincipal

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).

  1. BuildBeforeExport the data with the application of.
  2. BuildrearIn the application, I will import the data.When importing, it compares the principal information of the data to be imported with the principal information of the application (after building) and automatically converts the principal ID of the account (juser) of the data to be imported.

Minimal operation

From this mechanism, when adding or deleting a principal, it is reflected by importing the account model (juser).Specifically, it becomes the following operation.

  1. Export the account model (juser) in the pre-build application.
  2. Build and exchange applications.
  3. Import 1. Account model (juser) in new application.

The added principal is automatically reflected at the timing of 3.

For versions prior to R7.8.2, restart the Wagby application after 3.(Rebooting is unnecessary in R7.8.2 and later versions.