DEPT!@CUR.Label = DEPT!@POV.Label (1)Access Permission Type
This manual is in pilot operation.
|
| Applications of the Workgroup Type cannot use Access Permission Types, as detailed in Workgroup Type. |
What is an Access Permission Type?
An "Access Permission Type" is a Design Object that flexibly controls the range of ledger cells accessible by users based on their roles and organizational affiliations.
Access Permission Types represent access permissions such as:
-
Only viewing data from one’s own department & no updates allowed
-
Only viewing and updating data from one’s own division
-
Only viewing and updating personnel budget data across all departments
Features of Access Permission Types
(1) The 'Point of Reference' for Access Permissions can be Parameterized
As in the examples mentioned above, when defining Access Permission Types, the 'Point of Reference' for access permissions, such as "one’s own department" or "one’s own division," can be parameterized. That is, information specifying what "one’s own department" concretely means can be designated separately from the access permission definition.
Therefore, it is not necessary to create individual Access Permission Types for each organizational unit. For example, consider the case where you want to grant users from each department the right to "only view data from their own department." Even if there are 100 departments, there is no need to create 100 Access Permission Types. It is sufficient to create just one Access Permission Type that includes the condition "only view data from one’s own department."
Which department "one’s own department" refers to is set in another object called "Participant." Who is granted which Participant’s permissions is also set separately. By appropriately segregating and setting necessary information for access control in this way, setting up access security in fusion_place is made straightforward.
(2) Read and Write Permissions can be Set Separately
Access Permission Types allow separate settings for read permission conditions and write permission conditions.
(3) Different Types of Permissions can be Assigned According to User Group Roles
Access permissions vary depending on users' roles and department affiliations. An unlimited number of Access Permission Types can be created, and any Access Permission Type can be assigned to each "Participant."
In addition to a department that "can only view its own data," if there is a department that wants to "update and view data from all its subordinate departments," please set up two Access Permission Types representing each permission content. Then, assign one of the two Access Permission Types to the corresponding Participant for each department.
Area Definition Expressions
Access Permission Types include Read Permission Area Definition Expressions and Write Permission Area Definition Expressions. Both types of area definition expressions are evaluated for each ledger cell, and only if the result is "True" is reading or writing the value of that cell permitted (although writing may still be prohibited for other reasons).
If no area definition expression is specified, an expression that considers all ledger cells as "True" is assumed (thus, access to all cells is permitted).
⚠ If you want to prohibit access to all cells, enter "FALSE" in the area definition expression field (without double quotes).
How to Write Area Definition Expressions
Area definition expressions are a dialect of text expressions. For detailed grammar, please refer to Explanation of Text Expressions. Here, in addition to the characteristics of area definition expressions, we introduce several commonly used examples.
Characteristics
Similar to Mask Condition Expressions, in area definition expressions, the "current member" refers to the dimension member tied to the individual ledger cell under inspection (as mentioned earlier, the evaluation of area definition expressions is done for each ledger cell individually).
In addition, area definition expressions allow referring to the member specified by the "responsibility key" of the Participant to which the user belongs as the "Point of View Member". For example, the "Point of View Member" for the DEPT dimension can be retrieved with DEPT!@POV ("POV": Point of View abbreviation).
The Point of View Member can be used as the 'Point of Reference' for access permissions mentioned in "Features of Access Permission Types". Specifically, by judging the relationship between the "current member" and the "Point of View Member" in the area definition expression, different access permission areas can be specified for each Participant (see the examples below).
Examples
(1) Conditional Judgment Based on Dimension Member Label
Example:
| 1 | The label of the department (DEPT) dimension member related to the ledger cell matches the label of the department (DEPT) dimension member specified by the "responsibility key" of the Participant selected by the user. That is, the data is from one’s own department. |
| Element of the expression | Meaning |
|---|---|
DEPT |
Dimension labeled as |
DEPT!@CUR |
The "current member" of the above dimension ⚠ In area definition expressions, the "current member" refers to the member related to the target ledger cell. |
DEPT!@CUR.Label |
The label of the above member |
= |
Tests that the values on the left and right are equal |
DEPT!@POV |
The "Point of View Member" of the ⚠ In area definition expressions, the "Point of View Member" refers to the member specified by the "responsibility range key" selected by the user. |
DEPT!@POV.Label |
The label of the above member |
Note that .Label can be omitted, and the above expression can also be written as follows:
DEPT!@CUR = DEPT!@POV(2) Conditional Judgment Based on Parent-Child Relationship of Dimension Members - 1
Example:
DEPT!@CUR.is_descendent_of(DEPT!@POV) (1)| 1 | The department (DEPT) dimension member related to the ledger cell is a descendant of the department (DEPT) dimension member specified by the "responsibility key" of the Participant selected by the user. That is, the data is from a department under one’s own department. |
| Element of the expression | Meaning |
|---|---|
DEPT |
Dimension labeled as |
DEPT!@CUR |
The "current member" of the above dimension |
is_descendent_of(…) |
Method that returns "True" if the target member (left member) is a descendant of the member specified in the argument (right member) |
DEPT!@POV |
The "Point of View Member" of the |
(3) Conditional Judgment Based on Parent-Child Relationship of Dimension Members - 2
Example:
DEPT!@CUR.shares_ancestors_with(DEPT!@POV, TRUE, "DEPT_TYPE", "DIV") (1)| 1 | The department (DEPT) dimension member related to the ledger cell and the department (DEPT) dimension member specified by the "responsibility key" of the Participant selected by the user belong to the same division. That is, the data is from a department under one’s own division. |
| Element of the expression | Meaning |
|---|---|
DEPT |
Dimension labeled as |
DEPT!@CUR |
The "current member" of the above dimension |
shares_ancestors_with(…) |
Method that returns "True" if the target member (left member) and the first argument member (right member) have a common ancestor member that meets the conditions specified in the second to fourth arguments ⚠ An "ancestor member" includes oneself and one’s direct and indirect parent members. |
DEPT!@POV |
The "Point of View Member" of the |
TRUE |
The second argument of the |
DEPT_TYPE |
The third and fourth arguments of the |
DIV |
The fourth argument specifies the label of the value that the target member must hold for the property specified in the third argument. The above When the third and fourth arguments are combined, it means to limit the search target ancestor members to "divisions". |