Editions!@CUR.owner_label = @participant_labelProcess Management Functions and Access Control
This manual is in pilot operation.
|
Overview
When writing data (reflecting data) to the ledger in various processes of the process management function, only the data in the ledger cell range writable with the forms included in the form list specified in the submission package definition[1] is subject to writing.
In determining writability, the ledger access control function and the input restrictions set in the form are generally applied, but there are exceptions where these are not applied or are applied in a special way. Specifically, as shown in the table below.
(✓: Applied -: Not applied)
| Access Restriction Function | Ledger Access Control Function | Input Restrictions by Form | |||
|---|---|---|---|---|---|
Various Processes in Process Management Functions |
Cell Protection[2] |
||||
1. Reflecting process at the time of Reception and Reflect of submission package |
✓ |
✓ [3] |
✓ or - [4] |
✓ |
✓ |
✓ |
✓ [3] |
✓ or - [4] |
✓ |
✓ |
|
✓ |
✓ [3] |
✓ |
✓ |
✓ |
|
Ledger Editions and Access Control Used in Processes
As described in the explanation of Workspace, a ledger edition is generated for each participant involved in the process (see "Ledger Editions of Processes"). To control access to these ledger editions, you can include conditions related to ledger editions in the region definition formula in the access permission type. Here, we will explain how to describe the region definition formula for typical access control needs when using process functions.
Allow Access to the Edition of One’s Own Participant
Use the owner_label property of the ledger edition object and the function @participant_label.
| Formula Element | Meaning |
|---|---|
Editions!@CUR |
The ledger edition currently being accessed |
Editions!@CUR.owner_label |
Label of the participant who owns the above ledger edition |
＝ |
Checks that the value on the left side equals the value on the right side |
@participant_label |
Label of the participant who is reading/writing the data |
Allow Access to Submission Packages Submitted or Approved by One’s Own Participant
Use the is_submission property of the ledger edition object.
Editions!@CUR.is_submission| Formula Element | Meaning |
|---|---|
Editions!@CUR |
The ledger edition currently being accessed |
Editions!@CUR.is_submission |
Returns True if the above ledger edition represents a submission package, otherwise returns False |
Note that for Submission Packages as Ledger Editions, access requests themselves will result in an error if it is not a package submitted, received, or receivable by one’s own participant, so the above condition formula simply checks whether the ledger edition is a submission package.
Allow Access to Public Editions
Use the key property of the ledger edition object.
Editions!@CUR.key = "PUBLIC"| Formula Element | Meaning |
|---|---|
Editions!@CUR |
The ledger edition currently being accessed |
Editions!@CUR.key |
Key of the above ledger edition |
＝ |
Checks that the value on the left side equals the value on the right side |
"PUBLIC" |
Constant "PUBLIC" |
Since the "key" property is optional, the above condition formula can also be written as follows:
Editions!@CUR = "PUBLIC"Condition Description in Typical Cases
In typical cases, the access condition for ledger editions is to allow access only if any of the above three are met. In this case, the condition formula is as follows:
Editions!@CUR.owner_label = @participant_label OR
Editions!@CUR.is_submission OR
Editions!@CUR = "PUBLIC"For the Finalizing Participant for Published Data, it is usually necessary to grant access rights to the common workspace, etc., in addition to the above (e.g., when the finalizing participant uses the common workspace as their workspace without assigning a private ledger edition). In this case, the above condition formula is modified as follows:
Editions!@CUR.owner_label = @participant_label OR
Editions!@CUR.is_submission OR
Editions!@CUR = "PUBLIC" OR
Editions!@CUR = "WORKSPACE" ....Of course, the above condition formula can be combined with other condition formulas.
1. The range of ledger cells displayed in the form depends on the parameter values specified at the time of display. Therefore, the range of ledger cells writable in the form also depends on the parameter values. In determining writability here, the parameter values are given according to the rules described in "Parameter Values of the Submission Package" in the process definition.
2. Cell protection can be specified in any of the Report Format, Column Specification and Row Specification, or Cell Specification of the full-featured form. The effect is the same regardless of which one specifies it.
3. Writing access is determined based on the authority of the submitting participant, as if the target ledger edition is the same as the ledger edition of the submitter’s workspace (i.e., as if the key of the target ledger edition is the same as the key of the submitter’s workspace ledger edition). Therefore, it is not necessary to grant access rights to the data writing target ledger edition to the submitting participant.
4. In processes 1 and 2 in the table, it is possible to ignore the open/close status of the ledger (i.e., not impose writing restrictions based on the period). If you turn ON the "Do Not Apply the Ledger Open/Close Table When Reflecting Submission Package Data" item in the process definition, it will be applied that way (to apply changes to already generated processes, execute the process definition update). + This is based on the idea that it is more in line with the operator’s intention to make past data that is already closed writable as long as it is data collected in that process. For example, it is assumed that after completing the budget formulation process for FYX1 and closing FYX1 in the budget scenario, the budget formulation process data will be published to the shared workspace. In this case, if you do not ignore the open/close status of the ledger, (since the FYX1 budget is closed), the budget data will not be written to the shared workspace (i.e., it cannot be published).
5. In the data reflection process in the shared workspace, as the first step, the ledger editions of the workspace of all participants in the process are replaced with the ledger edition of the shared workspace, and in the second step, the data of the cells writable in the ledger with the submission package form among the contents of the workspace ledger edition before replacement are written to the ledger edition after replacement. The "existing data reflection process" described here means that second step.