Add the ability to emit platform wide notifications

[cstns]

Description

Added an admin API that can send platform wide notifications to users that fall into the provided roles.
Added a User model query that retrieves users based on provided roles.

Related Issue(s)

closes #4554

Checklist

• I have read the contribution guidelines
• Suitable unit/system level tests have been added and they pass
• Documentation has been updated
  • Upgrade instructions
  • Configuration details
  • Concepts
• Changes flowforge.yml?
  • Issue/PR raised on FlowFuse/helm to update ConfigMap Template
  • Issue/PR raised on FlowFuse/CloudProject to update values for Staging/Production

Labels

• Includes a DB migration? -> add the area:migration label

[codecov]

Codecov Report

Attention: Patch coverage is 92.45283% with 4 lines in your changes missing coverage. Please review.

Project coverage is 78.78%. Comparing base (f52c2cc) to head (4ea0309).
Report is 135 commits behind head on main.

Files with missing lines	Patch %	Lines
forge/notifications/index.js	83.33%	3 Missing ⚠️
forge/routes/api/admin.js	95.23%	1 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #4637      +/-   ##
==========================================
+ Coverage   78.74%   78.78%   +0.03%     
==========================================
  Files         311      311              
  Lines       14669    14748      +79     
  Branches     3354     3372      +18     
==========================================
+ Hits        11551    11619      +68     
- Misses       3118     3129      +11     

Flag	Coverage Δ
backend	78.78% <92.45%> (+0.03%)	⬆️

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

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[cstns]

The only task left is inserting data into the notifications table. I’ve added a basic implementation that loops through and inserts notifications into the database based on the roles query.

However, this approach could become problematic if there are many users or results, as it might cause a table lock on the notifications table and lead to other issues.

Should we stick with this for now?

[knolleary]

However, this approach could become problematic if there are many users or results, as it might cause a table lock on the notifications table and lead to other issues.

Should we stick with this for now?

I had a quick look at this part this morning. Had a couple thoughts, but need to poke at it a bit more once other unrelated tasks are complete. Will review tomorrow.

[knolleary]

Going to ship as-is. There are improvements to be made on the scaling of adding notifications to large proportions of users in the database; but for the low-scale usage of the feature we can ship now and improve later.

[knolleary]

Decided to hold back; want to validate the scaling issue first. Also, want to add the ability to target team tier as well as role.

Will pick up and complete in next few days.

[joepavitt]

@knolleary let me know once this is ready please, as want to send out a notification for the 2.10 Release.

[knolleary]

Have pushed a small refactoring:

1. replaces recipientRoles on the API with filter. This is an object that can contain different filter options. For this iteration the only property is roles - the equivalent of recipientRoles. This gives us room to move in the future with other filter options to target different selections of users
2. Added a bulkSend api for this use case - which uses bulkCreate to create notifications in batches of 200. This is all done under a single transaction which helps reduce load on the DB.

As I write this comment, realise I haven't dbl checked the UI tests for the api change I made... will see how that goes before marking this good to merge.

[cstns]

Should we get another set of eyes on the back-end changes? I'm not sure I can/should approve the changes

[knolleary]

@cstns I'll give it a fresh look over in the morning, but then we can move forward.

[knolleary]

Not working on postgres due to implicit casting between boolean/integer types in the query.

Need to fix and add some tests.

[knolleary]

Postgres fixed. Also, for the mock call, changed to use count rather than find as there's no need to return the actual data.

Finally, added some unit tests for the api side.

[cstns]

Should I merge the PR after I give it another quick check?