Enable different content moderation (editorial workflow) roles per top-level Section

[kevwalsh]

Background

User Story or Problem Statement

A CMS user's content moderation role is the same in every section.

Occasionally, we may want and editor to be able to edit and/or review in one section, but not publish in that section AND be able to edit, review and publish in another section.

How might we allow certain editors to be able to publish content, but only edit or review others?

Example use cases

• VACO user for VBA or VHA can edit and review changes to benefits hubs, but cannot publish them.
  • VACO user for VBA or VHA can edit, review and publish changes for content in VBA and VHA sections, AND publish them.

Discovery questions

• See how many edge cases in Teamsite, users with different roles in different TeamSite folders?

Possible implementations

• Handle this with business process - business stakeholders could go through OCTO to make changes, and remove access.
  • It turns out editors from the businesses are not really touching these pages anyway.
  • Some pages
• Build additional content moderation tools and apply them to certain content types, sections, or products (eg Benefits Hubs).

Affected users and stakeholders

• editors with access to multiple sections or products
• governance stakeholders

Hypothesis

A hypothesis may depend on a spike ticket to be completed.

We believe that _thissolution will achieve _thisoutcome. We'll know that to be true when this measurable outcome occurs.

Assumptions

• Tk
• Tk

(How will these assumptions be validated?)

Acceptance Criteria

• [ ] TBD

[jenniferlee-dsva]

Hi @kevwalsh - Adding some additional thinking here based on our discussion last week wrt your suggestion for possibly adding a third dimension for permissions -- i.e., so instead of just sections and user role(s), also possibly adding a tier or product dimension.

After giving it some thought, I think this is really the last resort solution and if possible, one I think we should avoid. The reasons are:

• Tiers are a very internal concept to help DEPO prioritize work. It is not entirely realistic in the wild. For example: VAMCs are a great example of a product that has tier 1, tier 2, and tier 3 types of content.

• Products - products are very granular and also somewhat fluid in concept. Does it correspond to a web page, set of web pages, a web site, a path within a domain? On TeamSite, "site folder" corresponds to the path within a domain - so every /name-of-path-after-the-va-gov is treated as if it is a website or product. (We'd end up basically with the same flat-but-super-flexible approach that TeamSite has -- which would force a lot of duplicative role assignments for ppl who need to be a publisher for lots and lots of products like every single VISN.)

1/ Right now, we have 5 vertical sections - VA, VBA, VHA, NCA, DEPO.

• (And within each vertical, there are subsections. I am not talking about the subsections within each vertical.)

2/ Today, a user can have assignment to multiple vertical sections, but only one role or set of roles.

3/ Is there a way that the BE could allow a person to have assignment to a user role PER vertical section?

Example - so that:

• A Jeff G can be a publisher for the VHA vertical -- which cascades down to all the VISNS, national health taxonomy, so on within that VHA upper most parent vertical.
• While also (after we move the benefit hubs to the DEPO vertical section) he could also be assigned as an editor-only for the benefit hub.
• (I think there's less risk here of VHA users going into VBA or NCA benefit hubs, so it wouldn't necessarily even need to be the granularity of "health benefit hub." I.e., they can just be given edit only access to a subsection called "Benefit hubs," knowing that they can only publish after PW reviews, and we wouldn't publish someone in NCA making changes to VBA pages.)

[kevwalsh]

I agree that adding a "Tier" idea is probably the wrong implementation, because the lines are hard to draw and indeed, a VAMC has all 3 "tiers". We are already adding a Product layer to the content model, for a variety of reasons, but i agree that it's probably not suitable for governance.

Before discussing the proposal, just a note about language: sections and their children are all just sections, so i don't think we should start calling top-level sections "Vertical sections" at this stage, and anything below that a "subsection". For now, i'd suggest just calling the top 5 "Top level sections" or something like that. So:

The proposal to distinguish content moderation by access to a "Top level section" proposal is a really interesting one and would warrant a proof of concept. There are some minor UX issues to think through. For example, the current experience for looking at the Owner field would need to change if an editor is looking "across" to another section. And the technical part is not trivial.

This epic would benefit from more discovery and brainstorming. I think we have the user stories we need, not sure if we've thought of all the possible ways of solving for them yet. My sense is that an application-based solution needs to be weighed against a business-process based one, at least in the medium term. (An application-based solution will need some business processes anyway!)

[jenniferlee-dsva]

Mostly agree but couple points of confusion:

VACO user for VBA or VHA can edit and review changes to benefits hubs, but not publish, but can publish changes to content

We mean: VBA, NCA, VHA top level section users can edit/review changes to benefit hub pages (whether or now we move them into the DEPO section), but not have publshing ability to benefit hub pages.

Outreach hub editors can edit outreach hub landing page but not publish those changes. Outreach hub editors can add events and outreach assets and publish them.

• I don't understand the second part of this.
• Do Outreach Hub Content Creators not have the ability to edit and publish events and assets? (That's why the creator also has to have Publisher role to be able to actually make assets and events live?)
• If ^ true, then yes, we basically don't want outreach publishers to be able to publish hub landing page changes to the interface/intro texts, landing page H1s, nav menu links. We want Outreach publishers to only be able to publish only events and assets.

(This one feels like it stems from an erroneous smooshing of asset and event data (business line owned data) with web pages and nav menu links (DEPO) owned product -- similar to how PDF forms and forms data are owned by form managers but the form landing pages are DEPO owned.)

[jenniferlee-dsva]

Desired: VACO users for VBA or VHA can edit and review changes to benefits hubs, but not publish those changes.

Content moderation roles: Editor, Reviewer, Publisher. Same for all content products. (Exclude Content Creators from this story.)

[EWashb]

We will most likely be revisiting this work after implementing CMS notifications. Notifications will feed into editorial workflows. Notifications MVP = emails