Closed jilladams closed 8 months ago
@swirtSJW Can you take a look at this
From planning:
Scratchpad for my findings: Will update as I go
Kev proposed name spacing the states by role
However i think that is going to be problematic since some have multiple roles and would see multiple states.
The problem does still exist (was not rectified in contrib modules)
Minimal but non-ideal solution does work. Multi select on the moderation state filters. Allows you to multiselect the multiple published and see them all.
Hmmm Module: State Machine might offer us a desired solution.
I have a combo filter showing.
Unfortunately the query is failing.
This is being generated from two workflows Our existing workflow An added workflow.
From scrum:
Making progress. I got it so the filter doesn't throw an error. But clearly the results are messed up as it is returning too many results.
It is duplicating results.
I got the dupes fixed, and the filter is largely working, but something still is not right with the results
This is almost working... just being minorly odd Here is an example using a secondary workflow.
@swirtSJW it would be helpful to document on here what we expect to need to do for standard views. Meaning: what burden are we adding for creating any future audit views that apply to multiple content types / editorial workflows? We'll need to know that for the discussion with CMS team, I think.
@jilladams part of the plan would have to be to convert all the current moderation state filters that are in use, to the new multiple moderation state filter. Its not really an option. It would have to be done because that old filter breaks as soon as we add a second workflow.
Roadmap (defining this is still in progress, will update as I go):
Flagging some theoretical risk / burden for Facilities in this plan around #4 / 6, wherein we are taking on ownership of making changes to all Views across the CMS, not just Facilities views, for our own sake. If buggy, that also means we have introduced a potential maintenance burden. I think we can volunteer to do the upfront work in order to get what we want as far as VBA workflow, BUT: when we review proposal in CMS Collab Cycle, we should clarify with CMS team that this would be for the initial lift, but we wouldn't own related maintenance ongoing.
Is that a reasonable way to be thinking? (@swirtSJW & @xiongjaneg FYSA)
Still having trouble getting this right. The filter is actually working, but the display of moderation state in the table is misleading/wrong.
I just discovered a second problem. Workflow states that are named the same, jump the boundaries from one workflow to the other if two or more workflows share the same machine name.
I have the multiple filter working perfectly Before
After
I just discovered a second problem. Workflow states that are named the same, jump the boundaries from one workflow to the other if two or more workflows share the same machine name.
If I understand this correctly, what you are calling out is:
Published
or Default Revision
While that does not seem like desired behavior, I do not think it should block implementing an iteration on workflows that implements 2 workflows. There are still many existing governance problems we could resolve even if all the workflow states that share the same name also have to share the same boolean settings.
ALso noting this just in case we want same machine & effect, but differing label
I submitted the upstream issue. https://www.drupal.org/project/drupal/issues/3382759 Will submit patch tomorrow.
Patch was submitted last night. It could use a followup round of tests to increase the likelyhood that it will get accepted, but that is not a blocker for us using it within our normal patch workflow.
So the roadmap exists higher up and has been updated. I believe we can close this and call it done.
@xiongjaneg or @jilladams let me know if you disagree.
@swirtSJW @xiongjaneg the ACs included scheduling time with Michelle to review proposed path forward -- is that done?
@jilladams I was not part of a meeting with Michelle. I am not sure if she has seen the roadmap or discussed it with @xiongjaneg
Related thread where Michelle has also weighed in: https://dsva.slack.com/archives/C0FQSS30V/p1693336269574529
Questions: Does the option of changing roles and permissions go away? Yes, this could be a change to workflow not roles/permissions.
What do we need to be able to show CMS Team? A simple document with our proposal and a summary of Steve's information.
What is the value to Veterans? Veterans get accurate information. Nothing is archived that shouldn't be archived.
Why can't we use existing methods? We want to present what makes this approach better or why this approach does something we can't do now. We need a new workflow to not allow people to archive who shouldn't be able to. In the way that we currently block someone from archiving a content type in a code way, there is currently no record of which content types we block.
Vet Center editors example: When starting in CMS, they were given the editor role and not able to publish until national gave approval. That's a manual role change for the user not related to workflow.
Workflow states don't perfectly match published status. "Published is not always published."
Did not test switching a workflow. Would we want to do this ahead of time for VBA? Or do we wait?
Is this still the right thing to do if we found out we couldn't do this for VBA? It's attainable but the unknown is time and effort.
Is there a use case this doesn't work for? Per content type, there may be ones that people should always be able to archive, even if accidentally because the downstream effect is minimal (e.g., events).
What about services? Are they archivable? A facility editor should be able to archive a service if not offered locally, except for required services. Required services would be coded so they can't be archived by an editor (existing workflow). Can make it a property of the node.
Helpful links: https://github.com/department-of-veterans-affairs/va.gov-cms/issues/11028 https://github.com/department-of-veterans-affairs/va.gov-cms/issues/5248 https://github.com/department-of-veterans-affairs/va.gov-team/blob/master/platform/cms/content-governance/content-moderation-roles/README.md
If I can't archive a VC facility, can I archive a CAP? It doesn't have to be by facility. It is by content type. Each content type can only be in one workflow.
Steve could use the new diagram content model to demonstrate workflow 2 in a demo environment as a method to share this with CMS Team.
What are the success measures? Number of issues related to mistakenly archived nodes, particularly facilities
Timeline? This is not blocking VBA work.
Any consequences for Drupal 10? The patch might not apply cleanly but that is a simple fix.
[ ] @xiongjaneg to draft and @mmiddaugh to edit a simple document for CMS Team to preview
[x] @xiongjaneg to stub a ticket for testing the patch Steve worked on
and Icebox it
Is the additional Workflow needed for VBA RO Pilot MVP? Considerations:
New VBA facilities will not be created during Pilot MVP. There would have to be change management on this later on if editors can archive VBAs.
There is a risk in switching workflows, particularly for existing editors. An additional workflow could co-exist for existing facilities, but this could create a mental load for facility maintenance and editor support. There is likely not a visible benefit to Veterans or editors.
We have at least 4 views in Drupal that would have to be converted a new filter to display multiple workflows. This will create additional work because of many admin views needing to be found and updated because VBA facilities show up on these admin views with the Moderation state filter, which is breaking due to multiple workflows. This could be a find a replace but would require testing.
There is a benefit to Veterans because CMS as the source of truth would mean more accurate information and fewer discrepancies in facility data and for a shorter period of time.
Next step is to take to CMS collab cycle. Scheduled for Oct. 2 with CMS product folks.
Description
VBA Regional Offices need specific permissions, with an explicit goal of preventing VBA Editors from publishing an RO before it has services and an operating status.
In June 2023, we proposed a permissions model that uses an Editorial Workflow. In Drupal, we currently have a single Workflow that governs all content types. We are proposing creation of a 2nd, separate Workflow that would be considered an Experimental Feature, used only for VBA ROs. If successful, additional content types could be migrated to the 2nd Workflow later. (Slack history)
However: the CMS Team / PO have expressed a preference for using Roles / Permissions, not a separate workflow. Because:
SO: we want to:
History:
ACs