VAMC System VA Police content type in the CMS

[swirtSJW]

User Story or Problem Statement

As a VAMC editor, I want to add custom information for my system to the police transparency page so that I can surface things for Veterans in my system.

Questions for refinement

• What fields do editors need (might not use any for MVP??)? Answer: None, especially for MVP.
• If we are expecting editors to interact with this content type, then should it have design review now? Answer: Not needed for MVP.

Resources

• Current content model
• Collab cycle IA design

Acceptance Criteria

• @davidmpickett drafts a spec for fields and reviews with engineers before implementation
  • Content type name _____?
  • machine name: vamc_system_police
  • field_administration
  • field_office (to connect to system)
  • field fetch fields for centralized content
  • perms match vamc_system_billing_insurance
• appropriate alias pattern
• Requires Content Model Documentation
• Requires design review
• Requires @laflannery a11y review
• Ticket is stubbed for KB article update

Design principles

Veteran-centered

• Single source of truth: Increase reliability and consistency of content on VA.gov by providing a single source of truth.
• Accessible, plain language: Provide guardrails and guidelines to ensure content quality.
• Purposely structured content: Ensure Content API can deliver content whose meaning matches its structure.
• Content lifecycle governance: Produce tools, processes and policies to maintain content quality throughout its lifecycle.

Editor-centered

• Purpose-driven: Create an opportunity to involve the editor community in VA’s mission and content strategy goals.
• Efficient: Remove distractions and create clear, straightforward paths to get the job done.
• Approachable: Offer friendly guidance over authoritative instruction.
• Consistent: Reduce user’s mental load by allowing them to fall back on pattern recognition to complete tasks.
• Empowering: Provide clear information to help editors make decisions about their work.

Team

• Facilities

[xiongjaneg]

@swirtSJW Michelle and I are inclined not to have editors edit any part this page for MVP.

[xiongjaneg]

@xiongjaneg Needs content model ticket link here
Edit: Updated content model

[davidmpickett]

@xiongjaneg This one might also need a point or two for me to help with spec

[xiongjaneg]

@davidmpickett added to AC

[xiongjaneg]

@xiongjaneg need ticket to update hook or script to run to generate 140 pages and put them in the right spots in the menu, etc.
Done: #16034

[davidmpickett]

Content spec

• Content Type label: VAMC System VA Police page
• Content Type machine name: vamc_system_va_police

Fields

• Title: VA Police
• Description: DO NOT USE - Hide from form display

Label	Machine name	Field Type	Notes
Enforce unique combo	field_enforce_unique_combo	Allow Only One	Unique field combinations = Related health care system (field_office)
Last Saved by an Editor	field_last_saved_by_an_editor	Timestamp
Related health care system	field_office	Entity reference
Section	field_administration	Entity reference	Should match related health care system
National [field label]	field_cc_[machine_name]	Entity Field Fetch fields	To match fields created in #15710

Permissions

• Editorial workflow: Restricted Archive Workflow

Permission	Content Editor	Content Reviewer	Content Publisher
VAMC System VA Police page: Edit any content	✅	✅	✅
VAMC System VA Police page: View revisions	✅	✅	✅
VAMC System VA Police page: Revert revisions	❌	❌	✅

[swirtSJW]

@davidmpickett this is fantastic. I do see a disconnect from @xiongjaneg's note about not expecting any editor to touch this page and the permissions you specified. Was there a change in direction?

[davidmpickett]

There won't be any fields they can do anything with for MVP. But I think we should still give the roles the standard permissions. The plan is to add additional fields that editors could control post-MVP.

Even with no interactive content fields, they would still need to go in and save it once a year to keep it off the Outdated Content report.

[jilladams]

From scrum:

• We can exclude Police pages from the aging content view, so they don't get pings.
• For MVP, we could exclude these Police pages from the VAMC admin content view as well. If we don't exclude, Editors would be able to see and edit, but save nothing.

Saving this for Steve to address in a future comment with more detail.

[swirtSJW]

The two options really come down to, "Should VAMC editors be able to ever see an edit tab or edit option while seeing this page or a listing of it in the System's section View?"
There are basically two options:

1. Yes they can edit it, but (at time of launch) it is page where there is nothing for them to edit.
2. No no editors other than admin and content_admin should be able to edit this page.

Regardless of the choice, this page ought to be exempted from the outdated content report and trigger. (a 1 pt ticket)

As @davidmpickett says though, if there will be fields that could be edited in the near future, then I like his idea of just going ahead with setting up the perms now.

[xiongjaneg]

Stubbed #16120 for the outdated content report ticket

[mmiddaugh]

Agree: this page ought to be exempted from the outdated content report and trigger.

Understanding about local editor input/access changed during a conversation with Police Services leadership in which we learned a single 24/7 non-emergency phone number will be made available via csv and any additional phone numbers and/or physical address will be best known/owned by local staff.

Access by local editors is post-MVP.

Questions:

• Is there any risk in adding permissions now?
• Is the proposal to add the fields for possible future local editor use now? If not, does it make sense to add those permissions at that time?

[swirtSJW]

Is there any risk in adding permissions now?

@mmiddaugh the only risk is in creating editor confusion.

If phone numbers will be maintained by local staff, then it makes sense to add them to the content type. (and maybe even migrate them in from the CSV??) The number of sources of truth on this is starting to get a bit concerning.

If we add the fields later, then we could always add the perms later. I guess it comes down to the time frame. If "later" is 3 months or less, we might as well do it now.

[swirtSJW]

Also if we are planning to add editorially controlled fields in the next 12 months, then there is no reason to intentionally remove this content type from the outdated content notifications because they will never get surfaced there in the first year anyway.

[davidmpickett]

BLUF - I don't think there's a huge risk either way. And 95% of the work for this ticket can be completed without a decision on this point, so this shouldn't be a blocker to Drupal devs starting the ticket.

• Is there any risk in adding permissions now?

It is not non-zero, but it very low in my opinion. All the fields on the Content Type will locked down in various ways, so local editors wouldn't be able to break anything.

The risk of not setting the permissions now is that future Facilities team members may spend unnecessary cycles trying to understand why something isn't working as expected. I'm thinking specifically here of the Sitewide Contract being up for recompete in April 2024.

Permissions are generally a "set it and forget it" part of Drupal that you put in place when you create something new. Not giving editing permissions to these 3 roles breaks the standard Permissions pattern for most content types. This would be an exception and therefore would require clear documentation so that future team members understand the intention.

• Is the proposal to add the fields for possible future local editor use now?

No. That would introduce risk and complexity we don't need for MVP

[mmiddaugh]

The number of sources of truth on this is starting to get a bit concerning.

Although we have several sources of truth for the data on the page, there is a single source of truth for a given data point (i.e., number of arrests comes from a single source, even if it is supplied by a different source than the data for incidents with weapon discharge).

Any contact information contributed by editors in the future will supplement the 24/7 non-emergency number we expect to receive from Police Services (such as the local emergency number or the physical campus location).

[swirtSJW]

Fields are created and that's about it.

[swirtSJW]

This content type is complete in this PR and is ready for design review, Accessibility review, and code review. #16169
Will add QA steps for each in the morning.

[xiongjaneg]

@jilladams This is still pending PR review

[davidmpickett]

Just noting that I spent a chunk of time today reviewing the PR and responding to comments. Two minor suggestions (SHOULD) and then one eyebrow raising thing that might be some known Tugboat quirk, but on it's surface feels approval-blocking to me (MUST).

[jilladams]

@xiongjaneg here too: From scrum notes and convo with Steve today, this one taking longer than expected to root cause the Sections issue that Dave flagged above, re: capacity for the remaining Drupal work in Sprint 98.

[swirtSJW]

All the issues were resolved and this has been merged. Should land on prod on monday.

[jilladams]

Present on prod, https://prod.cms.va.gov/node/add/vamc_system_va_police, closing.