Skip to content
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

Merged
merged 42 commits into from
Dec 4, 2024

Conversation

akabiru
Copy link
Member

@akabiru akabiru commented Nov 19, 2024

Ticket

https://community.openproject.org/work_packages/59436

What are you trying to accomplish?

  • Op#59433 Define Database Models for reminders
  • Op#59434
  • OP#59435
    • Contracts
    • Reminders create service - schedules notification creation at remind_at
      • Create a "reminder_notification" - join table that tracks notifications created from reminders
    • Reminders update service
    • Reminders delete service
  • Handle seeding and migrating of new manage_own_reminders permission

Screenshots

Screenshot 2024-12-02 at 5 45 26 PM

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

  • Added/updated tests
  • Added/updated documentation in Lookbook (patterns, previews, etc)
  • Tested major browsers (Chrome, Firefox, Edge, ...)

@akabiru akabiru added this to the 15.1.x milestone Nov 19, 2024
@akabiru akabiru self-assigned this Nov 19, 2024
@akabiru akabiru force-pushed the implementation/59433-define-database-model-for-reminders branch from 2e0428f to b466fba Compare November 19, 2024 13:31
@akabiru akabiru changed the title [#59433] Define database model for reminders [#59436] Set reminders for work packages to automatically generate date alert notifications (backend services) Nov 20, 2024
@akabiru akabiru force-pushed the implementation/59433-define-database-model-for-reminders branch from 745d3f8 to 78e2a7a Compare November 20, 2024 09:41
@akabiru akabiru force-pushed the implementation/59433-define-database-model-for-reminders branch from bd3c339 to 6137d1b Compare November 20, 2024 11:05
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
@akabiru akabiru force-pushed the implementation/59433-define-database-model-for-reminders branch from 753f8a0 to 3e6ab0d Compare November 21, 2024 12:42
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
@akabiru akabiru force-pushed the implementation/59433-define-database-model-for-reminders branch from 3e6ab0d to b471590 Compare November 21, 2024 22:55
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
@akabiru akabiru force-pushed the implementation/59433-define-database-model-for-reminders branch 3 times, most recently from f30c92a to eefbc1b Compare November 22, 2024 20:13
…tion

Introduce simple status enums to track various reminder states
@akabiru akabiru force-pushed the implementation/59433-define-database-model-for-reminders branch from eefbc1b to ae3f77d Compare November 22, 2024 20:14
…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.
@akabiru akabiru force-pushed the implementation/59433-define-database-model-for-reminders branch from 117fd17 to b636799 Compare November 27, 2024 09:39
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)
@akabiru akabiru force-pushed the implementation/59433-define-database-model-for-reminders branch from 7aa3f2b to 8053cb6 Compare November 28, 2024 18:00
Failing in CI - perhaps when ran in global context
@akabiru akabiru force-pushed the implementation/59433-define-database-model-for-reminders branch 2 times, most recently from 49b3ad2 to e9f5c93 Compare November 28, 2024 18:51
@akabiru akabiru force-pushed the implementation/59433-define-database-model-for-reminders branch from e9f5c93 to 2bebbd5 Compare November 28, 2024 18:59
@akabiru akabiru marked this pull request as ready for review November 29, 2024 14:15
@akabiru akabiru requested a review from jjabari-op November 29, 2024 14:15
@akabiru akabiru added this to the 15.2.x milestone Nov 29, 2024
Copy link
Collaborator

@jjabari-op jjabari-op left a 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
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

that seems very short

Copy link
Member Author

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.

Screenshot 2024-12-04 at 5 46 12 PM

@akabiru akabiru merged commit 300ce15 into dev Dec 4, 2024
13 checks passed
@akabiru akabiru deleted the implementation/59433-define-database-model-for-reminders branch December 4, 2024 14:50
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Development

Successfully merging this pull request may close these issues.

2 participants