I have a first draft of this ready for review: https://git.drupalcode.org/project/uswds_alert/-/tree/3517998-update-rea...
The issues have been created:
- https://www.drupal.org/project/uswds_alert/issues/3519139 ✨ Create USWDS Site Alert single directory component Active
- https://www.drupal.org/project/uswds_alert/issues/3519138 ✨ Create USWDS Alert single directory component Active
- https://www.drupal.org/project/uswds_alert/issues/3521039 ✨ Stub: Create non-USWDS single directory component Active
Discussion from meeting today:
- What happens if someone is already using a Sitewide Alert and has added their own
field_heading? - We will test to make sure nothing breaks
- Christian will merge this ticket as is
Another question about field machine names. What's best practice for naming fields? I know on the VA we would title our fields very specifically to their context. So the Heading field might be field_alert_heading rather than field_heading.
My understanding is that if two fields have the same name they share some settings and so being specific avoids potential collisions with other fields that someone may have. field_heading seems like it could be pretty common.
Display Order field in configuration
I've got a bunch of thoughts, but I don't think any of them should block merging. This functions as intended.
- Alert Message field is not required. This seems weird, having an empty alert doesn't seem like a valid use case. But this is probably something we can't/shouldn't mess with because it comes from the Sitewide Alert module?
- On Form Display and Display, is it possible for us to make the
field_headingcome beforemessageon install? Or is that too complicated because we're adding fields to existing type? It's a simple enough configuration change to make after install, but more asking for my own education about best practices in module architecture. - i just noticed that Sitewide Alert has a Display Order setting in the configuration. Makes me once again question whether adding the weight field is correct for MVP if there's already a system for ordering alerts built into the base module
- Another thing that's probably not our monkeys or our circus, but why are the Structure settings (Form Display/ Display etc.) for Sitewide Alerts under Configuration/User Interface rather than under Structure? Is this a limitation of modules, or just a choice the authors of Sitewide Alerts made?
davidmpickett → changed the visibility of the branch 3517998-add-a-readme.md to hidden.
Diagram created and decisions documented.
Second draft, now with proposed new fields and blocks in pink https://app.mural.co/t/civicactions3117/m/gratitudegarden1406/1744213980...
First draft of a entity model just mapping out the basics of the existing Sitewide Alert module to confirm my understanding https://app.mural.co/t/civicactions3117/m/gratitudegarden1406/1744213980...
davidmpickett → created an issue.
swirt → credited davidmpickett → .
Just weighing in here that our users at the Department of Veterans Affairs are also confused by this behavior. Issue # 3469265 🐛 Repeat setting is missing when editing a node Needs review also seems to be a duplicate of this issue.
Commenting for credit attribution
davidmpickett → created an issue.
davidmpickett → created an issue.
Comment for org credit
Here's a first pass
This seems like a good compromise. An additional enhancement to communicate this novel behavior to Site Builders might be to add some explanatory text to the Widget settings. Maybe something like:
Help text for URL field
The following default help text will be displayed for the URL field. "Start typing to find content or paste a URL and click on the suggestion below."
If you add your own help text in the field settings, it will display after the default help text.
This could be inserted between the Placeholder for URL and Placeholder for link text.
swirt → credited davidmpickett → .
swirt → credited davidmpickett → .
swirt → credited davidmpickett → .
davidmpickett → created an issue.
davidmpickett → created an issue.
Modeling this on the Entity Relationship Diagram, here's a series of drop downs that might power workflow diagrams:
- Chose Workflow to diagram
- Workflow #1
- Workflow #2
- Workflow #3
- Chose starting Workflow Element
- Workflow State
- Workflow Transition
- Chose starting Workflow State/Transition
- Draft
- In Review
- Published
- Chose depth
Starting from the Approved workflow state might look like this:
flowchart LR
A1(Draft)
A2(Draft)
B1(In review)
B2(In review)
C1(Approved)
C2(Approved)
C3(Approved)
D1(Published)
D2(Published)
E1(Archived)
E2(Archived)
A1 ~~~ C2 ~~~ A2
B1 -->|Approve| C2 ~~~ B2
C1 ~~~ C2 ~~~ C3
D1 ~~~ C2 -->|Publish| D2
E1 ~~~ C2 -->|Archive| E2
Starting from the Edit workflow transition might look like this:
Mermaid markdown:
flowchart LR
A(Draft)
B(In review)
D(Published)
E(Archived)
A -->|Edit| A
B -->|Edit| A
D -->|Edit| A
E -->|Edit| A
If and when there is support for adding a CMDocument for a base field ✨ CMDocument: Add support for documenting base fields Fixed , this display would be a great place to show/link to that documentation.
davidmpickett → created an issue.
Added screenshots to show the fields that show up for a given bundle in the Content Model Fields view compared to the fields that show up when Managing the Form Display the same bundle
I just encountered a bug on Content Model Fields that I think might be resolved by adding this plugin. For entity references that use views, they list the Target as "- via View filter entity_reference_1".
Entity_reference_1 is a generic placeholder. In order to figure out the actual Target, I need to go to the correct content type > manage fields > find the relevant field and click edit > scroll down to Reference type / View used to select the entities.
Screenshots attached
davidmpickett → created an issue.
swirt → credited davidmpickett → .