dsasser
commented
1 year ago This AC:
Implementation ticket = https://github.com/department-of-veterans-affairs/va.gov-cms/issues/11692, update with final plans
Is not possible to complete until we are through the CMS collab cycle and the implementation has been singed off by Dave Conlon. Given that, we will be unable to close this issue this sprint. unless we strike that from the required ACs.
I feel as though we have completed the essence of this ticket, which is to establish and propose a new plan to Drupalize the create account block. @wesrowe thoughts?
wesrowe
Description
User Story
As a Homepage Manager, I want to be able to manage the Create Account block in Drupal so that I can tweak it without a code change.
Details
This ticket is a SPIKE on how to Drupalize the Create Account block content on the updated homepage.
Questions that we need to resolve:
SPIKE Results
What Drupal pattern should we follow? e.g., another custom block type displayed by an EntityQueue?
Click to expand
A new Block + entityqueue is likely the ideal solution, given we are already using blocks + entityqueue for other areas of the home page, so this would not break into a new pattern. Do any of the existing blocks make sense to leverage? |Block Type||Fields| Alert - Alert body, Alert title, Alert type, Reusability, Section Promo - Image, Link, Section CMS Announcement - Alert body, alert heading, Submission guidelines, Type V2 Homepage benefit promo - Promo CTA, Promo Headline, Promo Text, Section V2 Homepage news spotlight - Image, Link, Link Text, Promo Headline, Promo Text, Section None of these really work. The required fields, and the field names/labels, do not lend themselves well to being used for other purposes, such as one as rigidly structured as this login block appears to be. That said, there are reusability options for fields, such that we do not need to create all new fields for this new block, and instead leverage existing fields that perform similar/identical functions from other blocks. This helps reduce overall field/database bloat.What permissions framework should we use? (e.g., same as homepage promo blocks?) Any issues or tradeoffs w.r.t. permissions?
Click to expand
Assuming homepage manager (Drupal role) is the owner/editor of this content, then we should follow the pattern of the new homepage blocks (v2 home page benefit promo, v2 home page news spotlight). Combined with the use of the Section access control, this gives us the same permissions framework as other blocks on the home page. This framework also applied to other home page elements such as menus, so keeping with that pattern is ideal. To recap the framework: Drupal Homepage Manager role is allowed create + edit permissions for new block types. Homepage Manager will assign the block to the `OPIA Home page` Section. Section (workbench access) controls the permissions for editing blocks. Homepage Manager is allowed to edit/add items to the new entityqueue.What would the Drupal UX/UI experience look like out of the box?
Click to expand
** Note the below screenshots represent a quickly-thrown-together content model for the sake of demonstrating out-of-the-box experience. Content and CMS design will need to weigh in on their areas of concern before it is committed to code. ### Block form  ### Entityqueue formAny issues concerning the front-end implementation?
Click to expand
No FE concerns identified. The new entityqueue query can be added to the `homePage.graphql.js` script and injected into home page liquid template variables to replace static text strings in `hero.drupal.liquid`.Acceptance Criteria