SPIKE: Determine approach for required services as well as removing / archiving existing services

[jilladams]

User stories

Required services
Admin able to archive required service.
Admins able to remove a required service.
Admins should be able to unarchive a required service.

Other users not able to archive required service.
Other users not able to remove a required service.
Other users not able to unarchive a required service.

All users can tell if a service is required or not.
Users can see and edit required services , but not archive or remove them. (striking through this last clause as redundant of user stories above.)

Removing services
As a Vet Center editor, I want to remove a facility service from my facility.
As a product owner, I want to manage the number of nodes in the system, and archive nodes that are no longer useful. (Speaking to: "orphaned" facility service that might no longer be associated with a facility.)

Considerations

Solution should be generalizable on Vet Centers today, and on VAMC / VBA potentially in the future.

ACs

Removing services

• Understand what "Remove" does today, in relation to Vet Centers & Vet Center facility services
  • Understand the VAMC paradigm for "retiring" a VAMC Facility Service today

Both

• Options are summarized with general level of effort for how to accomplish user stories
• Summary is reviewed with Product & next steps are identified / ticketed

Resources

Work in progress matrix of functionality

AC1

Removing services

Removing a Vet Center facility service via Inline Entity Form does the following upon Vet Center node save:

• removes the facility reference on the service by unsetting the value of the field_office, thanks to a corresponding entity reference (CER).
• saves the service node, again via CER
• changes the name of the service node
• removes the facility name in the service name because there is no value in the field_office field
• results in a title such as " - Telehealth".

The result is an orphan service with no apparent initially-associated facility, even though the facility can be inferred from the Section.

AC2

"Retiring" a VAMC Facility Health Service by Archiving

The current workflow:

• An editor edits a VAMC Facility Health Service
• The editor sets the moderation state to Archived
• The editor saves the VAMC Facility Health Service

When the editor goes to the node:view of the facility itself, they can see the facility services and their moderation states. From that page they can also either view the service by clicking the linked name of the service or edit the service by clicking the Edit button.

The editor can bring the service out of "retirement" for "one last job" by:

• Editing the VAMC Facility Health Service
• Setting the moderation state to Published
• Saving the VAMC Facility Health Service

[jilladams]

Dave plans to collaborate with Christian as needed.

[omahane]

@jilladams @davidmpickett As we're looking to go away from IEF, I want to make sure I understand the future need for the following:

As a product owner, I want to manage the number of nodes in the system, and archive nodes that are no longer useful. (Speaking to: "orphaned" facility service that might no longer be associated with a facility.)

If we go away from IEF, then we shouldn't have any orphaned services in the future because we will be using the archive process instead of the removal process for services no longer available at a Vet Center.

We can already see services that have been orphaned in this view.

Is there anything else we need to provide?

[davidmpickett]

Update, @omahane and I talked through his matrix on Friday and I will work on translating it into more product-focused documentation this week while he is out

[davidmpickett]

Update on my update. I have not had brain capacity to move this ticket forward this week

[davidmpickett]

Proposal

1) Archiving Required Services

Admin able to archive Required services

• Current state: True. Admins can archive from the service node. Going back to the Vet Center, however, you see no evidence that the service is archived.
• Proposed solution: No functional change needed. Possible QOL enhancements around secondary interface not a priority because it affects small subset of user base in a rare action.
• Estimated LOE: 0

Non-admin users should not be able to archive Required services

• Current state: ⚠️ False. While an editor can't archive a service from the main UX environment (IEF), they can go through /admin/content/ to get to the service. From there, they can edit a service as a node (rather than the reduced functionality of the IEF) and can an archive a service in the process.
• Proposed solution:
  • Remove the Archived moderation state on Node:Edit and Node:Create of Vet Center Facility Services
  • IF that service is Required
  • AND the user is not an admin
    
• Estimated LOE: 3
• Priority: Medium. This is core to the IEF removal work. Editors will be interacting directly with service nodes and thus more likely to accidentally archive a required service.
• Ticket stub: Make required services unable to be removed or archived #17676

2) Un-archiving Required Services

Admins should be able to unarchive a Required service

• Current state: True. On the service node, an admin can unarchive a required service.
• Proposed solution: No functional change needed.
• Estimated LOE: 0

Non-admin users should not able to unarchive a Required service.

• Current state: ⚠️ False.
• Proposed solution: Remove the "Edit" local task on required services for non-admins, allowing them access to only node:view.
  
• Estimated LOE: 3
• Priority: Low. There currently aren't ANY archived Vet Center Services and the nature of Required services makes it unlikely for this number to ever be meaningfully large. More of a future proofing.
• Ticket stub: TBD

3) Users can tell if a service is required or not

• Current state: ⚠️ Mostly true. Users can see this information when viewing the Vet Center Facility, but it is not visible when viewing editing individual services nodes.
• Proposed solution:
  • Vet Center facility node:edit should have a view of the facility services, identifying them as required or not.
    
  • Services node:edit should indicate whether that service is required
    
• Estimated LOE: 5 (might be on low end)
• Priority: High. This is integral to replacing the current IEF functionality
• Ticket stub: Add new Services View into Vet Centers node and remove IEF #18003 (listing view on facility node:edit) & Make required services unable to be removed or archived #17676 (box on facility service node:edit)

4) Removing services

Admins should be able to remove a required service

• Current state: True
• Proposed solution: *"Remove" is not a concept outside of IEF. Admins will retain ability to archive/delete services which have the same end result as removing. No change needed.
• Estimated LOE: 0

Non-admin users should not be able to remove a required service

• Current state: ⚠️ Mostly true. While this is currently the case via the remove functionality in the IEF, users do technically have ability to archive a service which would have the same FE impact. The "remove" action should be consolidated with the "archive" action so that there's one way to show that a service is no longer available at a given facility.
• Proposed solution: Remove the Archived moderation state on the node:edit of a Vet Center facility required service for non-admins.
• Estimated LOE: Accounted for in "Non-admin users should not be able to archive Required services"

5) Users can see and edit required services

• Current state: True
• Proposed solution: Replace IEF with a view. Only significant change will be editing services in a new tab rather than the same tab.
• Estimated LOE: Accounted for in "All users can tell if a service is required or not"

6) Users should be able to remove an optional service from a facility

• Current state: True
• Proposed solution: Remove will be replaced with Archive
• Estimated LOE: 0

7) As a product owner, I want to manage the number of nodes in the system, and archive nodes that are no longer useful.

• Current state: True. Through the Content Audit view.
• Proposed solution: No change needed
• Estimated LOE: 0

[davidmpickett]

^^^
@omahane - FYI that I am working on translating your spreadsheet to a linear proposal. I'm grouping by Drupal function first and user second. Also adding screenshot mock ups and comments about priority

[davidmpickett]

@omahane My proposal is ready for you to review before we share with product

[omahane]

@davidmpickett My first thought was about this box on Vet Center facility services node:edit. I added it to the issue where we are most likely to do the work:
#17676 (comment)

[omahane]

Another thought I had that might not be clear from this issue:

• By "All users can tell if a service is required or not," we are only speaking of those users who can access the node:edit of either the Vet Center facility or the Vet Center facility service.

[omahane]

@davidmpickett I made a slight change to the proposal, just to clarify that "All users can tell if a service is required or not" is covered by 2 tickets. I also added a suggested design change on the facility service node:edit for required services. Otherwise, I think we covered it.

[davidmpickett]

Another thought I had that might not be clear from this issue:

• By "All users can tell if a service is required or not," we are only speaking of those users who can access the node:edit of either the Vet Center facility or the Vet Center facility service.

Since this solution is generalizable, it would also mean VAMC editors for VAMC service and VBA editors for VBA services. We could reword it to "relevant users" or "Admin and non-admin users" since that's the main distinction we're drawing.
There's other implicit user distinctions in the proposal. Or maybe just "users can" like 5) and 6) are worded

[omahane]

Another thought I had that might not be clear from this issue:

• By "All users can tell if a service is required or not," we are only speaking of those users who can access the node:edit of either the Vet Center facility or the Vet Center facility service.

Since this solution is generalizable, it would also mean VAMC editors for VAMC service and VBA editors for VBA services. We could reword it to "relevant users" or "Admin and non-admin users" since that's the main distinction we're drawing. There's other implicit user distinctions in the proposal. Or maybe just "users can" like 5) and 6) are worded

I mostly wanted to account for the scope of users with access to node:edit, rather than any user of the CMS. So far, we haven't tried to account for node:view, though, I suppose we could.

[davidmpickett]

@Agile6MSkinner @mmiddaugh

Our proposal is ready for your review #17929 (comment)

BLUF: There's only a couple stories that would actually need dedicated tickets (both of which are stubbed). Most of the other stories are already in place or would be handled simultaneously with another story. There's an optional enhancement that we didn't stub a ticket for.

[davidmpickett]

End of Sprint update:
Product folks tagged for review on Slack & added to UX Sync agenda for Thursday

[mmiddaugh]

Thank you - the work is clear intended in #18003 and #17676 is clear

Do we have other issues to update the existing experience in the node (removing the table and connection to the service add/edit view?

Have we accounted for the experience for adding a new services?

• required services should be automatically added to a new Vet Center and therefore not appear in the list available following selection of "Add a new service"
• editors understand which services are available to be added to their Vet Center and which are already associated
• editors can see the moderation state of existing services (related: Vet Center services also have "In review" as a moderation state)

[davidmpickett]

Thank you - the work is clear intended in #18003 and #17676 is clear

Do we have other issues to update the existing experience in the node (removing the table and connection to the service add/edit view?

Covered by #18003

Have we accounted for the experience for adding a new services?

• required services should be automatically added to a new Vet Center and therefore not appear in the list available following selection of "Add a new service"
• editors understand which services are available to be added to their Vet Center and which are already associated

Removing these from the dropdown would be handled by #17674

• editors can see the moderation state of existing services (related: Vet Center services also have "In review" as a moderation state)

This will be part of the new view added in #18003

[davidmpickett]

Discussed in UX sync today #17669 (comment)

Follow up tickets still need some refinement, but they have been identified and updated