Access Permission Type

Designer
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 "Business Responsibility Unit." Who is granted which Business Responsibility Unit’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 "Business Responsibility Unit."

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 Business Responsibility Unit 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 Business Responsibility Unit 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 Business Responsibility Unit (see the examples below).

Examples
(1) Conditional Judgment Based on Dimension Member Label

Example:

  DEPT!@CUR.Label = DEPT!@POV.Label (1)
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 Business Responsibility Unit selected by the user. That is, the data is from one’s own department.
Element of the expression Meaning

DEPT

Dimension labeled as DEPT

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 DEPT dimension

⚠ 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 Business Responsibility Unit 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

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 DEPT dimension

(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 Business Responsibility Unit 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

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 DEPT dimension

TRUE

The second argument of the shares_ancestors_with method specifies whether to limit the search target ancestors to "active" members.
Here, "true (TRUE)" is specified, thus limiting the search.

DEPT_TYPE

The third and fourth arguments of the shares_ancestors_with method together specify a condition regarding the property value of the target ancestor member. The third argument is the label of the property to be used for filtering target members.
The above DEPT_TYPE indicates that the property value of "department type (DEPT_TYPE)" defined in the department dimension is used to filter ancestor members.

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 DIV represents a property value of "division".

When the third and fourth arguments are combined, it means to limit the search target ancestor members to "divisions".