-
Notifications
You must be signed in to change notification settings - Fork 2.4k
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
[#59436] Set reminders for work packages to automatically generate date alert notifications (backend services) #17229
[#59436] Set reminders for work packages to automatically generate date alert notifications (backend services) #17229
Conversation
2e0428f
to
b466fba
Compare
745d3f8
to
78e2a7a
Compare
bd3c339
to
6137d1b
Compare
Once a reminder is scheduled, track the job id- this way in case of rescheduling (snoozing reminder) there is a record we can rely on to have GoodJob reschedule directly. Further, we use this as a control to ensure unique job schedules. TODO: Once a notification is created from a reminder, create a "reminder_notification" - join table that tracks notifications created from reminders for further management
…date `update_column` is faster and updates the DB directly, skipping validations; which are not needed in this case. It is more important that we guarantee the job id is written into the database irrespective of any side effects from model validations
753f8a0
to
3e6ab0d
Compare
Arises from: 73aa20c Once a reminder is created we need to keep track of: (1) The scheduled job: this is done via Reminder#job_id which corresponds to a GoodJob::Job#id (2) Any Notification(s) resulting from the reminder This is important in order to easily handle any modifications to the reminder such as snoozing, editing & deleting reminders
const_defined? looks up ancestors OR descendants by default. Which resulted in a NameError ```ruby Failure/Error: "API::V3::Notifications::PropertyFactory::#{property_key.camelcase}".constantize NameError: uninitialized constant API::V3::Notifications::PropertyFactory::Reminder ``` To enforce descendants lookup, provide `false` as the second arg
3e6ab0d
to
b471590
Compare
As reminders are generally scheduled in the future, we need to keet track of (1) scheduled status - make it easy to track down the (good) job for edit/reschedule actions (2) notified at timestamp - prevents duplicate notifications, skip schedule when already notified
A notification cannot be linked to more than one reminder, every reminder should generate it's own unique notification.
Semantically on the recepient is relevant, as the actor is a reminder
f30c92a
to
eefbc1b
Compare
…tion Introduce simple status enums to track various reminder states
eefbc1b
to
ae3f77d
Compare
…notification" This reverts commit ae3f77d. Maintain a persistent record of reminder notifications as notifications are always retrievable by the user, e.g. via email, viewing "all" notifications. A reminder notification is only created IF there are no active unread notifications, hence when rescheduling, snoozing or editing a reminder then ensure all previous notifications are marked as read- as we should not have duplicate notifications for a given reminder.
117fd17
to
b636799
Compare
When a reminder schedule is updated, any existing unread notifications are marked as read; and new notification is scheduled
In CI env the change is not seen for some odd reason- passes locally ```ruby expected `Reminder#job_id` to have changed from "1" to "2", but did not change ```
When using AR #update_all, a direct SQL update is performed which means updated_at is not updated (lol)
exists? can be chained to where without having adverse effects See: https://docs.rubocop.org/rubocop-rails/cops_rails.html#railswhereexists
7aa3f2b
to
8053cb6
Compare
Failing in CI - perhaps when ran in global context
49b3ad2
to
e9f5c93
Compare
e9f5c93
to
2bebbd5
Compare
In case of wonky time comparison issues, we'd rather have the reminder rescheduled with minimal tolerance than not having the reminder set at all
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.
Great work @akabiru!
The only thing I've found was the max length of the notes, which I think is too short. Should be discussed with Wieland probably.
As everything else looks good, I approve this PR!
|
||
module Reminders | ||
class BaseContract < ::ModelContract | ||
MAX_NOTE_CHARS_LENGTH = 80 |
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.
that seems very short
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.
Good eye! We discussed this actually and 80 chars was the arrived spec. We can revisit and easily change if too short.
Ticket
https://community.openproject.org/work_packages/59436
What are you trying to accomplish?
reminders
remind_at
manage_own_reminders
permissionScreenshots
Note
Reminder note covered in #17323
What approach did you choose and why?
Reminders are set as a polymorphic association to allow for any future extension to other models such as comments, activities or wiki pages (which are out of scope for this first version)
At present a user can only create their own reminders; if there is a need to create for other users, an explicit
recipient
can be added to the reminders table. Right now, we take a minimal approach.Merge checklist