-
Notifications
You must be signed in to change notification settings - Fork 6
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[#1760] Implemented user feed #933
Conversation
04f9382
to
0290024
Compare
Codecov ReportAttention:
Additional details and impacted files@@ Coverage Diff @@
## develop #933 +/- ##
===========================================
+ Coverage 93.11% 94.80% +1.69%
===========================================
Files 829 857 +28
Lines 29142 30046 +904
===========================================
+ Hits 27135 28485 +1350
+ Misses 2007 1561 -446 ☔ View full report in Codecov by Sentry. |
0290024
to
1e36d3f
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good overall 👍, just a few minor remarks/questions
@@ -48,6 +49,10 @@ def handle(self, *args, **options): | |||
f"The email was sent to the user {receiver} about {plans.count()} expiring plans" | |||
) | |||
|
|||
# hook into userfeed | |||
for p in plans: | |||
plan_expiring(receiver, p) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've noticed a pattern with the userfeed hooks: the function names are not very descriptive, which is why every time you're hooking into the userfeed you need to add comments to indicate what you're doing.
Alternatively, you could try the following pattern:
- import the hook functions (e.g.
plan_expiring
) inuserfeed.hooks.__init__
- in
management.commands.plans_expire
:from open_inwoner.userfeed import hooks as userfeed_hooks
for p in plans: userfeed_hooks.plan_expiring(receiver,p)
- modify the relevant patch in
test_plans_expire
:@patch("open_inwoner.plans.management.commands.plans_expire.userfeed_hooks.plan_expiring")
The code would be self-explanatory, and comments would be unnecessary. The same pattern would work for the other cases (I think).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
OK this is also how some of the timelinelogs works so let's do that.
… fixed type annotations
…d-in, fixed html of case_status_changed message
057eb41
to
7c91b42
Compare
@stevenbal @pi-sigma I applied the PR fixes. Also: there was a mistake in the logic where the incoming-notification handler would check and bail early for emailable Users and would never reach the userfeed hook if the users had a bad email or email-notifications disabled. I fixed it in the last commit. |
Review notes:
It's a lot of files, but to get an idea of how it works first look at:
open_inwoner/userfeed/feed.py
for theget_feed(user)
that is the main entry for retrieval and display (in the plugin etc)open_inwoner/userfeed/hooks/*.py
for the 'hook' functions that create items of a specific type, the function to mark some as completed, and their optional 'adapter' class that generalizes the type for display byget_feed()
(and the template etc)Everything else is just glue to make it work or to tie it into the rest of the application. Note the liberal use of patch/mock in the tests to keep the user feed specific tests out of the other parts of the code.
In the future we'll add more item types to the choices/hooks/adapters.
To test the plugin put it on the homepage, and then run this command to add a test message:
These never expire, so delete from
/admin/userfeed/feeditemdata/
. To find valid--user
User id's use the command without arguments and it prints staff users: