search

department-of-veterans-affairs / va.gov-cms

Editor-centered management for Veteran-centered content.
https://prod.cms.va.gov
GNU General Public License v2.0
97 stars 69 forks source link

[Discovery] Node status-dependent permissions #13783

Open davidmpickett opened 1 year ago

davidmpickett commented 1 year ago

Description

As a Facilities team member, I would like to differentiate between CMS actions that change the node status and those that don't, so that I can prevent CMS editors from accidentally making high-impact changes that impact patient safety.

Our current permission schema does not distinguish between workflow transitions that change node status and those that don't.

Node status 0 = unpublished Node status 1 = published

Since workflow transitions don't map cleanly to node status changes, we can't restrict user permissions solely via workflows and content moderation roles. The first two categories below show all the times in which there they do align nicely and we could resolve this permission use case with a 2nd workflow that had slightly different permissions for Content Publishers than the main Editorial Workflow.

Transitions that never change node status

Transitions that always change node status

Transitions that sometimes change node status

*The Archive and Publish transitions encompass multiple use cases

Related cards

Possible solutions

Not mutually exclusive

Route A - Spilt Archive and Publish transitions into multiple transitions to delineate use cases

(AKA solve it with configuration as much as possible) Team - Dave P, Blake, Jo, Stefanie

Route B - Detect node status and restrict actions based on that

(AKA what engineering magic can we add?) Team - Steve W, Edmund, Tony T

Acceptance Criteria

davidmpickett commented 1 year ago

See https://github.com/department-of-veterans-affairs/va.gov-cms/issues/12911

timcosgrove commented 1 year ago

I'm not sure the focus on the node status is the right approach. I am much in favor of your 'Route A'. These sorts of workflow changes are exactly what the Workflow / Content Moderation system is meant to achieve.

Looking at the current transitions that are causing problems:

Transitions that sometimes change node status Archive From: Draft, In review, Approved To: Archived If node status = 0, then this transition does not change the status Publish From: Draft, In review, Approved To: Published If node status = 1, then this transition does not change the status

It is true that currently the 'Publish' transition can include transition from Publish -> Publish, and therefore node state doesn't change. Similarly, some of the statuses for the Archive transition do not result in a node status change, and some do.

The transitions are under our control and can be augmented. For example, if you are trying to separate out the ability to publish content for the first time vs publishing content that is already published, you can separate those out, into say 'Publish' vs 'Update'. Similarly, there could be an 'Archive without publishing' transition that separates out the movement of Draft, in review, approved to archive from the 'Archive' transition that transition. IOW, what you describe in Route A.

I don't think node status is relevant separately from 'Published' status. Node status 1 maps to Published state; node status 0 maps to all other states. What is important is applying roles/permissions to the transitions, and it sounds like to meet the use cases you're describing we simply need a more nuanced set of transitions.

timcosgrove commented 1 year ago

The scenarios that need addressing are:

davidmpickett commented 1 year ago

@kmariepat-cityfriends I'm moving this to the bottom of the Prioritized for Refinement pipeline based on timeline and priority conversations in Roles & Permissions meetings.