Task/FP-1375: Admin controlled messages

[duckonomy]

Overview:

Allow arbitrary and dismissable SectionMessage generation by admin (through core/admin) for components.

Related Jira tickets:

• FP-1375

Summary of Changes:

1. Created a /intromessages/custom/ endpoint (GET: Get templates & messages, PUT: Update unread state).
2. Create a CustomMessage UI component as a wrapper around SectionMessages to utilize state.customMessages.
3. Implemented necessary sagas/reducers to interact with the /intromessages/custom/ endpoint.
4. Made messages of type intro have a dismiss button.

Testing Steps:

0. Make sure to run migrations within the core_portal_django container: ./manage.py migrate
1. Make yourself staff or superuser.
2. Go to core/admin.
3. Create a Custom message template.
4. Go to the component you made it for (Will need refresh).
5. Ensure that it is correctly rendered
6. Repeat 3-5 for various different configurations (even multiple messages for single component) and ensure that they render accordingly
7. Ensure that dismissed (click x) messages do not show up.
8. Go to core/admin again.
9. Try removing some that aren't dismissed.
10. Refresh portal.
11. Ensure that the deleted messages do not show.

UI Photos:

Screen.Recording.2022-03-24.at.2.14.26.PM.mov

Notes:

1. (For CMD) Should there be a text limit for messages?
2. I wanted to refactor intromessages related components (both frontend/backend) into a more generic messages component. But wasn't sure how the migration process would go. Would there be a way to achieve this?
3. (For CMD) The info message type style does not seem to have an icon (SectionMessage, Message). Thus, the dismiss button (x), which is a child of the icon does not render.

[codecov]

Codecov Report

Merging #615 (1b3da0b) into main (b3aa730) will decrease coverage by 0.00%.
The diff coverage is 66.42%.

@@            Coverage Diff             @@
##             main     #615      +/-   ##
==========================================
- Coverage   67.79%   67.79%   -0.01%     
==========================================
  Files         423      426       +3     
  Lines       13077    13173      +96     
  Branches     2394     2414      +20     
==========================================
+ Hits         8865     8930      +65     
- Misses       3921     3951      +30     
- Partials      291      292       +1     

Flag	Coverage Δ
javascript	70.37% <41.33%> (-0.24%)	⬇️
unittests	65.74% <95.38%> (+0.18%)	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files	Coverage Δ
...t/src/components/Allocations/AllocationsLayout.jsx	80.00% <ø> (ø)
...rc/components/Applications/AppLayout/AppLayout.jsx	89.18% <ø> (ø)
client/src/components/Dashboard/Dashboard.jsx	72.22% <ø> (ø)
client/src/components/DataFiles/DataFiles.jsx	75.00% <ø> (ø)
client/src/components/History/History.jsx	93.75% <ø> (ø)
...ent/src/components/ManageAccount/ManageAccount.jsx	55.00% <ø> (ø)
...lient/src/components/Onboarding/OnboardingUser.jsx	96.15% <ø> (ø)
client/src/components/UIPatterns/UIPatterns.jsx	0.00% <ø> (ø)
client/src/components/_common/Section/Section.jsx	75.00% <ø> (ø)
...al/apps/portal_messages/migrations/0001_initial.py	100.00% <ø> (ø)
... and 14 more

[edmondsgarrett]

LGTM, works as described.

[rstijerina]

Nice work! Left a few comments, but overall 👍

[rstijerina]

I wanted to refactor intromessages related components (both frontend/backend) into a more generic messages component. But wasn't sure how the migration process would go. Would there be a way to achieve this?

@duckonomy Django supports custom migrations, so one way to achieve that could be to deprecate the old model and migrate data over in a single new migration file. We've done something similar in designsafe, though that was a bit simpler

[rstijerina]

Marking as "Request Changes" to keep track

[duckonomy]

@rstijerina

1. Refactored /intromessages/ in the backend to a more generic /messages/ folder. Also changed frontend intro.sagas.js and intro.reducers.js into message.sagas.js and message.reducers.js.

I'm not sure how this will affect the existing migrations.. because there is a dependency on the moved file/directory.

    dependencies = [
        ('message', '0001_initial'),
    ]

If this doesn't work out, we could rollback from 9681a8b.

2. Adjusted TextField to CharField due to your comment about allowing new lines and added 200 char limit in the according of our conversation in slack.

3. I wasn't sure how to allow resolve this case at the moment. Currently, both IntroMessages and CustomMessages requires a relation to a user to keep track track of unread or dismissal status. So, routes that do not require authorization like public-data aren't supported for now. I'm not sure if we should allow these message would be allowed to be dismissed or purely admin-handled. If dismissable, do we do what we used to do and keep it in localStorage?. If this is required, I could make a ticket tackling this issue.

[rstijerina]

3. I wasn't sure how to allow resolve Task/FP-1375: Admin controlled messages #615 (comment) at the moment. Currently, both IntroMessages and CustomMessages requires a relation to a user to keep track track of unread or dismissal status. So, routes that do not require authorization like public-data aren't supported for now. I'm not sure if we should allow these message would be allowed to be dismissed or purely admin-handled. If dismissable, do we do what we used to do and keep it in localStorage?. If this is required, I could make a ticket tackling this issue.

@duckonomy Yes, just what I was thinking too. We could use localStorage if the user is unauthenticated. New ticket sounds perfect 👍

[duckonomy]

5. I wasn't sure how to allow resolve Task/FP-1375: Admin controlled messages #615 (comment) at the moment. Currently, both IntroMessages and CustomMessages requires a relation to a user to keep track track of unread or dismissal status. So, routes that do not require authorization like public-data aren't supported for now. I'm not sure if we should allow these message would be allowed to be dismissed or purely admin-handled. If dismissable, do we do what we used to do and keep it in localStorage?. If this is required, I could make a ticket tackling this issue.

Yes, just what I was thinking too. We could use localStorage if the user is unauthenticated. New ticket sounds perfect 👍

👍 Created ticket FP-1644

[rstijerina]

Looking great! Just a few more comments

[duckonomy]

@rstijerina

1. Changed introMessageName to messageName
2. Changed batch behavior to single message update
3. Re-did migration
4. Changed route name to portal_messages
5. Improved readability of messages in admin panel.

[rstijerina]

@duckonomy Looking great, just a couple more comments!

[duckonomy]

@rstijerina

1. Simplified payload (templateId and unread) for PUT request for updating custom messages.
2. Renamed introMessages to introMessageComponents and introMessageName to messageComponentName to reflect what state.introMessages actually is (map of the state of a message for certain component). I think this makes more sense and is coherent with the use of the the prop in Section and SectionMessages for customMessages as well.

[rstijerina]

LGTM!