Use case: Complex access control based on workflow state

Created on 13 March 2024, 4 months ago
Updated 5 April 2024, 3 months ago

Problem/Motivation

Here is the use-case we would like to implement:

  • For each content-type, in each workflow state, we need to be able to configure:
    • Who can view and/or edit each part (an ECK entity embedded in the node via IEF) based on:
      • The current user's role, OR
      • The current user is "assigned" to the specific node (via a user-reference field), OR
      • The current user is the node's author

Proposed Solution

The simplest and most maintainable way to implement this appears to be to:

  1. Create an ECA model that disables all access to edit any Part field, across all related content types.
    1. This should ensure that users are only granted access by subsequent ECA models.
  2. Create an ECA model for each workflow state across all related content types. For each model, we:
    1. Create CONDITIONs to check each of:
      1. Current user is node author
      2. For each assignment field, current user ("Condition: Current user ID" plugin) matches token (eg. `[node:field_part_1:entity:field_role_assignee:entity:id]`)
      3. For each relevant role, the current user has that role ("Condition: Role of current user" plugin)
    2. Create ACTIONs to grant edit access ("Form field: set access" plugin) to each Part field (eg. `field_part_1`)
    3. Create EVENTs to trigger whenever field access is being evaluated ("Determining entity field access" plugin) for each Part field.
      1. We can then specify the successors to each of these based on the relevant CONDITIONs, and the ACTION matching the EVENT's configured Publication Part field.

Currently, the above does not take the workflow state into account. As it stands, we would need to:
- In (2.1) we would need to add a CONDITION to check the current workflow state ("compare workflow field value" plugin -- provided by this module)
- In (2.2) we would need to create a dummy ACTION that enables ANDing conditions ("Chain action for AND condition" plugin)
- Finally, we would need to add an additional successor for each of the ones in in (2.3.1) that adds the workflow state CONDITION with the special AND ACTION.

I believe that the extra complexity and redundant configuration can be avoided by creating a new EVENT plugin that replaces the one in (2.3). Basically, it would extend the "Determining entity field access" EVENT plugin to add a workflow state filter, making it "Determining entity field access in workflow states".

Feature request
Status

Active

Version

1.0

Component

Code

Created by

🇨🇦Canada ergonlogic Montréal, Québec 🇨🇦

Live updates comments and jobs are added and updated live.
Sign in to follow issues

Comments & Activities

Production build 0.69.0 2024