[Permissions] Homepage manager role needs the ability to create FW Banners & edit Path field

[FranECross]

Status

[2024-08-15] [Fran] Dave P completed his review and recommendation is to add the ability to create a Full Width Banner to the existing Home Page Manager role (which Josh already has). Slack thread here providing info to Michelle M. [2024-08-14] [Fran] Dave P will look into roles; another ticket will be created if drupal new role is needed. Does not need to be implemented in the upcoming sprint if a new role is needed.

Description

Josh Tuscher has a Content Publisher role, and in that role, he can modify and archive full width banners, but can't create them.

Randi Hecht has confirmed that she would expect OPIA to be able to create new Full Width Banners. Slack convo

Consider if there is an existing role that can be assigned, without providing Administrator permissions, or if a new role needs to be created.

Additional Information

• Jill confirmed this via Tugboat
• Jill confirmed that a content publisher, in the VACO section, which includes OPIA Alerts and Promo banners section, SHOULD have permissions to create new Full Width Banners (Slack convo.)
• Jill confirmed that at this time, Administrators can create new FWBs

Regarding Permissions of Full Width Banners and the interplay of Sections: Jill got the Permissions part of Full width banner permissions to load, and can see that Content Publishers are not generally allowed to create new FWBs. BUT: I don't really understand the interplay of Sections, and how they affect role permissions on content type actions. So a Drupal eng will need to speak to that. (Took a shot of Vet Center permissions as a contrast that sort of helps see that Sections is doing a lot for us in this realm, I think.)

Sections (Taxonomy) Information

Summary (from Jill) of the info below:

A content type has permissions for each role. A user has roles. A user has Workbench assignments that correlate to a section. And if a user has the correct role, and Workbench section for the content they're interested in: they can do stuff defined by the role permissions.

Info from Ian Sears:

• Sections (Taxonomy) in the UI lives here
• When we Edit the Term... (the Taxonomy section) we are able to choose the tab "Section members" One of the Section Member is the Workbench Group created as a candidate for this Term-Edit_SectionMember area.
• As you know and understand, Roles restrict permissions. In our CMS we also use a concept/module called WorkBench. What we've done is break out all the VAMC Systems, and each Vet Center (just examples here) as individual things in WorkBench. You can think of these kind of like WorkBench "Sections". Each of these... even further-restricts privileges and permissions. At the end of the day, we provide you a ROLE enabling you to Edit VAMC..."stuff" and then enable that in a specific WorkBench Section, like VA Tampa health care, or Watertown Vet Center. To see this in action, take a look at this which is the Workbench access for the user Zachary Hughes

User story

AS A Content Publisher in the VACO section I WANT the ability to create Full Width Banners SO THAT I don't rely on CAIA to create them for me, and so that I'm not tempted to simply edit an archived one, which is problematic in that any user who dismissed the banner previously won't see this 'edited' version of the archived / republished banner.

Engineering notes / background

Pull request is up that adds the permission to create FWB to the Homepage manager role: https://github.com/department-of-veterans-affairs/va.gov-cms/pull/18958

However: the Path field is not editable for a Homepage manager. Looks like that is controlled by a custom module https://github.com/department-of-veterans-affairs/va.gov-cms/blob/fe080b2efb86459900e581ea0974895c606f003c/docroot/modules/custom/va_gov_banner/src/EventSubscriber/EntityEventSubscriber.php

The PR will need an update to allow Homepage Managers to modify the Path field when creating new Full Width Banners (/node/add/banner)

Quality / testing notes

In lower environments/Tugboat, you can login as Joshua.Tuscher@va.gov using the global lower envs password, to test.

Acceptance criteria

• [ ] Users assigned the role Homepage Manager are able to create Full Width Banners and populate required fields and Path
• [ ] Notify PM (Fran Cross) when released
  • [ ] Fran to notify Randi Hecht
  • [x] Notify Grace K, and Michelle Dooley of the added permission to this role
  • [x] Notify Helpdesk of updated policy for Homepage Manager role
  • [ ] Fran to close the loop in the Slack thread here
  • [x] Update related KBs

[FranECross]

There was a new role created for an education user. Dave P to look into if there are existing roles.

[mmiddaugh]

@davidmpickett I'm not sure the new editor role I mentioned during refinement is actually relevant after all, but here is the issue for reference: Create Rates Editor Role #18451

[davidmpickett]

Suggested solution: Use the existing Homepage Manager role and add the permission Full Width Alert: Create new content

There are only 6 users with the Homepage Manager role:

• danielle.thierry@va.gov
• david.conlon@va.gov
• Michelle.Northuis@va.gov
• Randi.Hecht@va.gov
• Michelle.Northius@va.gov
• Joshua.Tuscher@va.gov

All of them aside from Josh are a Content Admin or above, so they can add any type of Content. Adding this Create permission to the role wouldn't change anyone's powers aside from Josh. AND it would only give Josh this power without granting him any other powers.

The relevant product question here is whether creating a Full Width Banner is a logical aspect of the role of Homepage Manager. If so, this is the way to go. If Josh needs this permission for an entirely different reason, not related to the Homepage Manager part of his job, then the permission would belong in a different Drupal role. @mmiddaugh @FranECross

[davidmpickett]

Renaming this ticket to remove the references to Content Publisher and Sections as they are actually irrelevant. Our governance schema separates Content creation permissions from Workflow/Moderation permissions

[davidmpickett]

End of Sprint Update:

• This ticket was an injection
• Waiting for final decision from @mmiddaugh (see Slack thread) before moving forward
• I have a PR draft ready if this direction is approved, otherwise I can come up with an alternate proposal

[davidmpickett]

Direction was approved in slack

[jilladams]

The SPIKE part is done, but the permissions update itself isn't. That's hte only AC, so this will roll to SPrint 11 to get PR review / approval, merge and deploy https://github.com/department-of-veterans-affairs/va.gov-cms/pull/18958.

Michelle also noted we need to make the CMS team aware of the permissions change, but not block on approval.

[jilladams]

In Sitewide cross-team sync today, Erika approved the plan to add the Create FWB permission to the Homepage Manager role. That PR is now unblocked. Erika also requested:

1. That we share this news with Helpdesk, for their awareness when giving new users Homepage Manager role permissions in the future. (They should update a related runbook.)
2. We revise any related KBs about creating new Full Width Alerts to make sure they're still accurate

[jilladams]

Re: KBs and helpdesk awareness:

• How to do I create a Full-width Alert Banner? is already tagged as a VA.gov Homepage related article
• Created VA.gov Homepage account administration policy, that spells out that we need Michelle's approval to add new people to this role, and shared with Helpdesk here: https://dsva.slack.com/archives/CDHBKAL9W/p1724279559631059?thread_ts=1724277597.962409&cid=CDHBKAL9W

[jilladams]

Moving back to current sprint not started and unassigning Dave. The PR that's up is mostly in good shape, however: when logged in as Josh Tuscher, the Path field isn't editable on the node/add/banner form. Looks like that is controlled by a custom module https://github.com/department-of-veterans-affairs/va.gov-cms/blob/fe080b2efb86459900e581ea0974895c606f003c/docroot/modules/custom/va_gov_banner/src/EventSubscriber/EntityEventSubscriber.php

An engineer will need to look into why that is / what we need to adjust in terms of field/permissions to make it possible for the Homepage Manager role to not only create new FWB, but also modify the Path field.

[davidmpickett]

Because I can't help myself, further spelunking:

VA.gov Event subscriber

This is the place where we are disabling the Path field on Full Width Banners for non-admins.

  /**
   * Disable the url paths field on entity forms.
   *
   * @param array $form
   *   The entity form.
   */
  public function disablePathsField(array &$form): void {
    if (!$this->userPermsService->hasAdminRole()) {
      $form['field_target_paths']['#disabled'] = TRUE;
    }
  }

VA.gov User Perms Services

/**
   * Checks to see if the current user has an admin level role.
   *
   * @param bool $administrator_only
   *   If check should only be for administrator role.
   *
   * @return bool
   *   TRUE if has an admin role, FALSE otherwise.
   */
  public function hasAdminRole(bool $administrator_only = FALSE) : bool {
    $current_user_roles = $this->currentUser->getRoles();
    // Roles to consider as admin.
    $admin_roles = !$administrator_only ? ['administrator', 'content_admin'] : ['administrator'];
    $admin_role_count = count(array_intersect($admin_roles, $current_user_roles));

    return ($admin_role_count > 0) ? TRUE : FALSE;
  }

• This is where we do the work to determine if the current user is an admin or not
• The function hasAdminRole is probably doing what it should be doing
• We could write a new, more general function here that would check if a user has a specific role. e.g. hasSpecificRole which would accept an argument of the role(s) we are looking for.
• For the situation of Full Width banner and disabling the Path field we'd probably want to check if the user hasAdminRole OR hasSpecificRole = homepage_manager and disable the field if Neither of those returns true.