Spike: Remove inline entity form (IEF) from Vet Centers

[xiongjaneg]

Problem statements

• When an editor edits a Vet Center Service, they have to do so using the Inline Entity Form on the Vet Center node. This does not update the last saved by an editor field on the Vet Center Service node
  

• When an editor edits a Vet Center Service, they have to do so using the Inline Entity Form on the Vet Center node. This does not provide a revision log message field so no new revision log message is saved. This makes it so that revision gets the same log message as the previous log message.

To Reproduce

Steps to reproduce the behavior:

1. Go to a vet center'/node/3719/edit'
2. Scroll down to the services, then click the edit button on the service.
3. Make a change to the service.
4. Save the Vet Center Facility node.
5. Find the service you just edited in /admin/content?title=&type=vet_center_facility_health_servi&moderation_state=All&owner=All
6. Look at the date and time of your revision, notice it does not match the date of the Last saved by a human field

Proposed solution

Get rid of inline entity forms for services so that editors edit the node directly.

• Remove IEF from Vet Center Facility
• Alter Vet center dashboard to point to a list of vet center services rather than the node
• Might need an alteration of FE code if it is using the IEF connection rather than the reverse entity reference.

ACs

• Proposed solutions are documented.
• Proposed solutions are reviewed with team (could use UX Sync or other synchronous meeting).
• Follow-up tickets are created/edited.

[jilladams]

From mid-sprint:

• We're going to have to remove Inline Entity form, so we shouldn't try too hard to get it working inline.
• There's a model on VAMC System Billing and Insurance, Register for Care pages, etc that have embedded views for related non-clinical services. Those views show the service, and have a pointer to go over to the Service node to edit it, or add a new one that takes you out to the add new form. (not changing it inline.)
• The right approach might be to think about ways to just display / viewable, and point editors out to edit/add, vs. getting it working inline.

[Becapa]

Before getting too deep into a different issue I wanted to add my thoughts here:

Option 1 - Viewfield

One option is to use a Viewfield on the Vet Center content type in a similar fashion as the top task page content types (i.e. Billing & Insurance) include non-clinical services on their pages.

Benefits:

• There is already a paradigm in place where this is working that can essentially be copied and tweaked a little bit to work with Vet Centers.
• It already includes links for editors to click on to edit or add new pieces of content from the Vet Center page.

Considerations:

• Viewfield doesn’t currently show a column for when the related content is required or optional. I think this could probably just be added as a field to the View that the Viewfield would be pulling in.
  • @davidmpickett says - Can a view focused on Services at a specific facility do a look up to the Service Taxonomy per service and pull down the Required Vet Center Service Info?
• There isn’t a link for removing optional rows. I’m not sure how often this function is currently used with the IEF form and whether or not it needs to be included.
  • @davidmpickett says - The logic of Removing vs Archiving is one of the semantic differences between IEF and Content Moderation workflow. It's one of the reasons IEFs are breaking the logic of our CMS. This will have to be a shift in editor understanding.
• The links for editing and creating take users away from the Vet Center page. This will likely just mean a little bit of extra training for the editors.
  • @davidmpickett says - These could open in a new tab to prevent loss of their work on the Vet Center

Option 2 - Entity Browser - Table

Benefits:

• This option would provide users with buttons on each row that allow them to edit or remove that row of content by opening up a modal which has that node’s edit form in it.
  • @davidmpickett says - What would removing mean in this case? Would it be the same as the IEF where a link between the nodes is severed without changing the Moderation State? Or would it actually be them archiving?
• It does appear to be the full edit form in the modal so wouldn’t suffer from the same issues as the IEF edit (like not updating the ‘last saved by editor’ field).
  • @davidmpickett says - Editing in a modal feels riskier than editing in a new tab

Considerations:

• This option doesn’t look like it has a way to show the required/optional column, though, so that would likely need to be added with custom code in a similar way that it already is with the current implementation (IEF).
• This option also doesn’t include a way to create new services. That would likely need to be added in it’s own field just below which would navigate users away from the page to a node creation page. Which is essentially the same way the Viewfield option does it.

Option 3 - Recreate bottom of VAMC Facility Node View

• I have no clue how this is generated but it seems like there's some custom code doing a form alter rather than using Widgets + Sitebuilding to add a list of Services to the Node View of every VAMC facility
• Example: https://prod.cms.va.gov/madison-health-care/locations/william-s-middleton-memorial-veterans-hospital#block-views-block-services-block-1

---

I don't think that either of these options should require having to change the Vet Center dashboard since it just links to the Vet Center edit form with an anchor to the section that shows the Services. (@davidmpickett says Depending on implementation, we may need to change the anchor link, but that's relatively easy)

The 'Entity Browser - Table' option does seem like it would be a little bit of a higher lift by needing more custom code so I'd maybe lean toward the Viewfield.

@omahane & @davidmpickett Do either of you have any thoughts or suggestions about either of these options (or a completely different approach)?

[omahane]

The code that shows what is required vs optional is in va_gov_vet_center/src/EventSubscriber/EntityEventSubscriber.php, specifically modifyIefServicesFormDisplay().

[jilladams]

Let's take a min to discuss this in sprint planning since tomorrow is Michael's last day and Christian's been thinking about it to take this over / make final recommendation / get us to tickets created to satisfy ACs.

[davidmpickett]

@Becapa Thanks for digging into the possibilities here. I just edited your comment above to reformat it to make it a little easier to parse the points of comparison

[davidmpickett]

Existing example of Viewfield

Existing example of Entity Browser - Table

[davidmpickett]

Existing Vet Center Service IEF

Vet Center Service Audit View

[davidmpickett]

VA Services Audit View

[davidmpickett]

Just added option 3 for the sake of completeness. I don't every really know what's going on there, but it is filling a similar purpose (but in a weird way).

Block layout with visibility settings

(Note: the above (link to demo) is from the node:view, but is not available via node:edit). When a VAMC facility health service is created, the facility itself is updated by Corresponding references (link to demo), specifically local_health_service_to_facility.

(edited by @omahane )

[omahane]

Option 1 (Viewfield)

This works for node:view well, but the while we have it currently working on node:edit for the top pages (thanks to a patch Jay Darnell wrote), it will definitely take more investigation to figure out the node edit.

Option 2 (Entity browser - Table)

Current examples don't seem to need the same kind of filtering we'd need to bring in the right ones initially. We'd need to use an entity reference view filtered to this facility. Some risk there.

Option 3 (Adding a view via form_alter)

This is the easiest way, using a view with arguments to pull in the correct items. The View can even show the current moderation state. The Edit link can open in a new tab.

Questions:

• How does remove work?
  • I'm not sure.
• Creating new would be in another tab.

[davidmpickett]

Notes from UX Sync

• Option 1 is out. It's not a stable solution and does offer any functionality that couldn't be achieved from option 3
• The call between options 2 and 3 will need more investigation
• @davidmpickett will stub follow up tickets:
  • UX flow ticket for editor experience
  • Front End spike for understanding how query is working and if it's inherently tied to the IEF linkage in a way that would necessitate option 2 vs 3
• @omahane will stub follow up Drupal tickets:
  • Documenting current way that we winnow Vet Center services list down when clicking Add New Service
  • Possible routes for making required Vet Center services actually required

[omahane]

Here's the first ticket about "winnowing":
#17674

[omahane]

Here's the one about making "required" items actually required: #17676

[omahane]

@mmiddaugh @davidmpickett I know we're looking to make a design ticket, but this is what I have so far if I added the services through a view (you'll see it after the IEF on node:edit):
https://pr17664-evkadxkewezkbjkntbuggeeddpgjws7z.ci.cms.va.gov/node/3867/edit

I'd figure out how to change the table captions, but right now the links of the service go to the view of the facility service and edit links go to edit the service and are set to take the editor back to the facility edit screen on save.

[davidmpickett]

Stubbed UX ticket: #17680

[davidmpickett]

FE Stubbbb #17681

[davidmpickett]

@jilladams I think this is good to close now that stubs have been created, but I'll let you make the call

[jilladams]

4 tickets added to epic, queued for refinements. Closing! Go team.

[davidmpickett]

@omahane FYI - I tested your POC to see how it handled Optional Services and right now they are coming in as a second table. Not something that needs to be fixed now (since this was already going above and beyond), but wanted to show you / leave a note for our future selves