infrastructure/extensions-website
4
8
Fork 10
Code Issues 20 Pull Requests 2 Projects Releases Wiki Activity

Notification emails #80

Merged
Oleg-Komarov merged 31 commits from notifications into main 2024-04-18 16:11:20 +02:00
Conversation 0 Commits 31 Files Changed 38 +805 -12
Oleg-Komarov commented 2024-04-15 19:10:28 +02:00
Owner
Copy Link

Implementation for #72 based on https://github.com/justquick/django-activity-stream/

Summary:

  • create an Action object, specifying a corresponding Extension object as a target and other relevant objects (Rating, ApprovalActivity, AbuseReport) as action_object (search code for action.send to see where it happens)
    • there is one exception when we don't have an action_object - when we submit a new extension for a review, but this could be restructured as creating a first ApprovalActivity item, TODO revisit this
  • use follow provided by actstream to specify relations between users and extensions, use different flags (author, moderator, reviewer) to explicitly manage those relations; proactively call the follow to make sure that users are subscribed before an Action interesting to them is created;
    • one downside here is that each moderator needs to follow each extensions individually, but this potentially allows to explicitly unsubscribe from activity on extensions that are not interesting to a given user
  • introduce VERB2FLAGS mapping to define when a given Action needs to generate a Notification for a follower of a particular type (=flag) based on the Action's verb
  • process Notification records by a new send_notifications management command that sends emails
  • add a profile setting to disable notification emails

First iteration includes only internal (@blender.org) emails.

If you have a DB with some preexisting data, you need to run ./manage.py ensure_followers command to retroactively create expected follow relations.

Next steps (out of scope for this PR):

  • refine notification texts: current Verb usage may be not grammatical and is not covered by i18n
  • UI: templates for showing notifications in user profile, marking notifications as read, unread counter in the header (there is some views code in this PR, but it it not surfaced to the users yet)
  • remove the internal email check
Implementation for #72 based on https://github.com/justquick/django-activity-stream/ Summary: - create an Action object, specifying a corresponding Extension object as a `target` and other relevant objects (Rating, ApprovalActivity, AbuseReport) as `action_object` (search code for `action.send` to see where it happens) - there is one exception when we don't have an `action_object` - when we submit a new extension for a review, but this could be restructured as creating a first ApprovalActivity item, TODO revisit this - use `follow` provided by actstream to specify relations between users and extensions, use different flags (author, moderator, reviewer) to explicitly manage those relations; proactively call the `follow` to make sure that users are subscribed before an Action interesting to them is created; - one downside here is that each moderator needs to follow each extensions individually, but this potentially allows to explicitly unsubscribe from activity on extensions that are not interesting to a given user - introduce `VERB2FLAGS` mapping to define when a given Action needs to generate a Notification for a follower of a particular type (=flag) based on the Action's verb - process Notification records by a new `send_notifications` management command that sends emails - add a profile setting to disable notification emails First iteration includes only internal (`@blender.org`) emails. If you have a DB with some preexisting data, you need to run `./manage.py ensure_followers` command to retroactively create expected follow relations. Next steps (out of scope for this PR): - refine notification texts: current `Verb` usage may be not grammatical and is not covered by i18n - UI: templates for showing notifications in user profile, marking notifications as read, unread counter in the header (there is some views code in this PR, but it it not surfaced to the users yet) - remove the internal email check
Oleg-Komarov added 16 commits 2024-04-15 19:10:33 +02:00 
currently save as draft also submits for review, TODO investigate
Oleg-Komarov added 1 commit 2024-04-16 16:00:00 +02:00
Oleg-Komarov added 1 commit 2024-04-16 17:27:34 +02:00
Oleg-Komarov added 1 commit 2024-04-16 17:33:34 +02:00
Oleg-Komarov added 1 commit 2024-04-16 17:59:31 +02:00
Oleg-Komarov added 1 commit 2024-04-16 19:33:19 +02:00
Oleg-Komarov added 1 commit 2024-04-18 12:25:48 +02:00
Oleg-Komarov added 1 commit 2024-04-18 12:34:51 +02:00 
postpone till we start creating ApprovalActivity
Oleg-Komarov added 1 commit 2024-04-18 12:50:43 +02:00
Oleg-Komarov added 1 commit 2024-04-18 13:22:46 +02:00
Oleg-Komarov added 1 commit 2024-04-18 13:23:02 +02:00
Oleg-Komarov changed title from WIP: notifications to notifications 2024-04-18 13:33:52 +02:00
Oleg-Komarov added 1 commit 2024-04-18 14:06:46 +02:00
Oleg-Komarov added 1 commit 2024-04-18 14:49:32 +02:00
Oleg-Komarov added 1 commit 2024-04-18 14:55:44 +02:00
Anna Sirota added 1 commit 2024-04-18 15:57:11 +02:00
Oleg-Komarov added 1 commit 2024-04-18 16:00:11 +02:00
Anna Sirota approved these changes 2024-04-18 16:10:32 +02:00
Anna Sirota left a comment
Owner
Copy Link

LGTM

LGTM
Oleg-Komarov merged commit bd3a17a19b into main 2024-04-18 16:11:20 +02:00
Oleg-Komarov deleted branch notifications 2024-04-18 16:11:20 +02:00
Oleg-Komarov changed title from notifications to Notification emails 2024-04-19 11:10:13 +02:00
Sign in to join this conversation.
Reviewers
No reviewers
Anna Sirota
Labels
Clear labels   
Priority
Critical
The priority is critical

  
Priority
High
The priority is high

  
Priority
Low
The priority is low

  
Priority
Normal
The priority is medium

  
Reviewed
Confirmed
Issue has been confirmed

  
Reviewed
Duplicate
This issue or pull request already exists

  
Reviewed
Invalid
Invalid issue

  
Reviewed
Won't Fix
This issue won't be fixed

  
Status
Abandoned
Somebody has started to work on this but abandoned work

  
Status
Blocked
Something is blocking this issue or pull request

  
Status
Need More Info
Feedback is required to reproduce issue or to continue work

  
Type
Breaking
Breaking change that won't be backward compatible

  
Type
Documentation
Documentation changes

  
Type
Enhancement
Improve existing functionality

  
Type
Feature
New functionality

  
Type
Report
Something is not working

  
Type
Security
This is security issue

  
Type
Suggestion
New ideas and proposals

  
Type
Testing
Issue or pull request related to testing

No Label
Priority
Critical
Priority
High
Priority
Low
Priority
Normal
Reviewed
Confirmed
Reviewed
Duplicate
Reviewed
Invalid
Reviewed
Won't Fix
Status
Abandoned
Status
Blocked
Status
Need More Info
Type
Breaking
Type
Documentation
Type
Enhancement
Type
Feature
Type
Report
Type
Security
Type
Suggestion
Type
Testing
Milestone
Clear milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
No Assignees
2 Participants
Notifications
Due Date
The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: infrastructure/extensions-website#80
No description provided.
Delete Branch "notifications"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?