Add notification table and model for in-system notifications by samindiii · Pull Request #69 · thoth-tech/doubtfire-api

samindiii · 2025-05-18T07:32:03Z

Description

This PR contains backend changes from PR:60 by Sahiru. The first five commits are Sahiru's and have already been reviewed in the relevant PR. In his PR, he created the backend for the Staff Grant Extension Feature and additionally created the backend notification system for emails.

This PR contains the backend notification system for in-system notifications. Since we currently do not have a way to persist notifications to display on the onTrack homepage, I created a notifications table and associated model. This table will store notifications for each user along with an associated message. This functionality can be extended in the future to store a boolean read value etc. The model has a relation with the user object so that we can access notifications for a specific user.

In terms of the Staff Grant Extension feature, a notification is created whenever an extension is granted successfully. This means we have a way of persisting the notification so that it doesn't just exist in memory but can be stored until it is read and deleted by the user. Additionally added tests to check that a notification is created when an extension is granted successfully.

Type of change

New feature (non-breaking change which adds functionality)

How Has This Been Tested?

To test this:

In your terminal, change directory to doubtfire-api - if you are in doubtfire-deploy, simply run the following

cd doubtfire-api

Run the following to apply pending migrations and update your database schema:

rails db:migrate

Run all test files using the following command:

rails test

Run the staff grant extension test using the following command:

rails test test/api/staff_grant_extension_test.rb

Additionally, if you want to test the notifications system integration with the front end, pull the front end code from PR:353 This means you can now view your notifications on the ontrack homepage.

Login as student (astudent, password)
Open a rails console
Create a new notification for user_id: 13 (a_student has a user_id of 13 in my db- it might not be the same for you)
Notification.create!(user_id: 13, message: "Test notification for student 13")
Navigate to your homepage and check that you have a new notification (red number on top of the bell)

Checklist:

My code follows the style guidelines of this project
I have performed a self-review of my own code
I have commented my code, particularly in hard-to-understand areas
I have made corresponding changes to the documentation if appropriate
My changes generate no new warnings
I have added tests that prove my fix is effective or that my feature works
I have created or extended unit tests to address my new additions
New and existing unit tests pass locally with my changes
Any dependent changes have been merged and published in downstream modules

If you have any questions, please contact @macite or @jakerenzella.

Enable staff to grant extensions to multiple students without formal requests. Reuse existing student extension logic through a new service for consistency. Supports flexible academic support and streamlines staff workflows. Relates to the OnTrack Staff Grant Extension design documentation.

…rpolated strings This aligns the test file with the string formatting convention used in the rest of the codebase. Single quotes are preferred when string interpolation is not needed, improving consistency. Reviewed as part of peer feedback.

Linked extension_comments_api (student-requested extensions) to use the shared ExtensionService, previously set up for staff-granted extensions. This refactor ensures both student and staff extension flows use the same logic, improving consistency and reducing duplication.

Implemented backend logic to send emails to tutor and student when extensions are granted. Also enable it so the front end can use the returned information from the api to display notifications.

A comment line change made in the staff grant extension feature branch that hasn't been updated here. Changing to keep the consistency.

SahiruWithanage

Hey Samindi !

I've reviewed the pr and it looks solid! The code is concise and follows the project's patterns well. I like how you've structured the database with a clean notification model connected to users and your API endpoints for fetching and deleting notifications are well-implemented.

A few minor suggestions that might be worth considering: adding some basic validations to the Notification model (e.g., presence/length for message), adding tests specifically for the notification API endpoints to ensure complete coverage and implementing pagination for the GET endpoint as notifications could accumulate over time (for an example someone might not click this at all for a long time and decides to click it only to get flooded with notifications).

I ran the Rails tests and no issues came up related to this implementation, which is a good sign but worth considering adding some test cases specific for this feature.

Overall, this provides a good foundation for the in-system notifications that accomplishes the goal of showing extension notifications to students. Great work!!

JoeMacl

Tested everything and it’s working great! Code is well structured and easy to follow.

As Sahiru mentioned, it’d be great to add some basic validations to the notification model like presence: true and maybe a character limit for the message. Also, adding pagination to the GET /notifications endpoint would help handle cases where students accumulate a lot of notifications over time.

Overall, great job! :)

aNebula · 2025-06-12T14:25:05Z

@samindiii LGTM. Please open an upstream pull request against 9.x branch in /doubtfire-lms/doubtfire-api.
Remember to include the description and link frontend PRs (if they are opened, and vice-versa)

- Add notifcation factory - Add unit tests for notifications - Only send first 20 notifications to front end - Have a max characters of 500

samindiii · 2025-08-10T07:49:35Z

Fixed up the code based on Sahiru and Joe's suggestions. Added a new test for the notifications API
rails test test/api/notifications_api_test.rb

…abot/bundler/websocket-driver-0.8.2 chore(deps): bump websocket-driver from 0.7.7 to 0.8.2

samindiii · 2025-05-18T07:32:03Z

Description

This PR contains backend changes from PR:60 by Sahiru. The first five commits are Sahiru's and have already been reviewed in the relevant PR. In his PR, he created the backend for the Staff Grant Extension Feature and additionally created the backend notification system for emails.

This PR contains the backend notification system for in-system notifications. Since we currently do not have a way to persist notifications to display on the onTrack homepage, I created a notifications table and associated model. This table will store notifications for each user along with an associated message. This functionality can be extended in the future to store a boolean read value etc. The model has a relation with the user object so that we can access notifications for a specific user.

In terms of the Staff Grant Extension feature, a notification is created whenever an extension is granted successfully. This means we have a way of persisting the notification so that it doesn't just exist in memory but can be stored until it is read and deleted by the user. Additionally added tests to check that a notification is created when an extension is granted successfully.

Type of change

New feature (non-breaking change which adds functionality)

How Has This Been Tested?

To test this:

In your terminal, change directory to doubtfire-api - if you are in doubtfire-deploy, simply run the following

cd doubtfire-api

Run the following to apply pending migrations and update your database schema:

rails db:migrate

Run all test files using the following command:

rails test

Run the staff grant extension test using the following command:

rails test test/api/staff_grant_extension_test.rb

Additionally, if you want to test the notifications system integration with the front end, pull the front end code from PR:353 This means you can now view your notifications on the ontrack homepage.

Login as student (astudent, password)
Open a rails console
Create a new notification for user_id: 13 (a_student has a user_id of 13 in my db- it might not be the same for you)
Notification.create!(user_id: 13, message: "Test notification for student 13")
Navigate to your homepage and check that you have a new notification (red number on top of the bell)

Checklist:

My code follows the style guidelines of this project
I have performed a self-review of my own code
I have commented my code, particularly in hard-to-understand areas
I have made corresponding changes to the documentation if appropriate
My changes generate no new warnings
I have added tests that prove my fix is effective or that my feature works
I have created or extended unit tests to address my new additions
New and existing unit tests pass locally with my changes
Any dependent changes have been merged and published in downstream modules

If you have any questions, please contact @macite or @jakerenzella.

Enable staff to grant extensions to multiple students without formal requests. Reuse existing student extension logic through a new service for consistency. Supports flexible academic support and streamlines staff workflows. Relates to the OnTrack Staff Grant Extension design documentation.

…rpolated strings This aligns the test file with the string formatting convention used in the rest of the codebase. Single quotes are preferred when string interpolation is not needed, improving consistency. Reviewed as part of peer feedback.

Linked extension_comments_api (student-requested extensions) to use the shared ExtensionService, previously set up for staff-granted extensions. This refactor ensures both student and staff extension flows use the same logic, improving consistency and reducing duplication.

Implemented backend logic to send emails to tutor and student when extensions are granted. Also enable it so the front end can use the returned information from the api to display notifications.

A comment line change made in the staff grant extension feature branch that hasn't been updated here. Changing to keep the consistency.

SahiruWithanage

Hey Samindi !

I've reviewed the pr and it looks solid! The code is concise and follows the project's patterns well. I like how you've structured the database with a clean notification model connected to users and your API endpoints for fetching and deleting notifications are well-implemented.

A few minor suggestions that might be worth considering: adding some basic validations to the Notification model (e.g., presence/length for message), adding tests specifically for the notification API endpoints to ensure complete coverage and implementing pagination for the GET endpoint as notifications could accumulate over time (for an example someone might not click this at all for a long time and decides to click it only to get flooded with notifications).

I ran the Rails tests and no issues came up related to this implementation, which is a good sign but worth considering adding some test cases specific for this feature.

Overall, this provides a good foundation for the in-system notifications that accomplishes the goal of showing extension notifications to students. Great work!!

JoeMacl

Tested everything and it’s working great! Code is well structured and easy to follow.

As Sahiru mentioned, it’d be great to add some basic validations to the notification model like presence: true and maybe a character limit for the message. Also, adding pagination to the GET /notifications endpoint would help handle cases where students accumulate a lot of notifications over time.

Overall, great job! :)

aNebula · 2025-06-12T14:25:05Z

@samindiii LGTM. Please open an upstream pull request against 9.x branch in /doubtfire-lms/doubtfire-api.
Remember to include the description and link frontend PRs (if they are opened, and vice-versa)

- Add notifcation factory - Add unit tests for notifications - Only send first 20 notifications to front end - Have a max characters of 500

samindiii · 2025-08-10T07:49:35Z

Fixed up the code based on Sahiru and Joe's suggestions. Added a new test for the notifications API
rails test test/api/notifications_api_test.rb

…abot/bundler/websocket-driver-0.8.2 chore(deps): bump websocket-driver from 0.7.7 to 0.8.2

samindiii · 2025-05-18T07:32:03Z

Description

This PR contains backend changes from PR:60 by Sahiru. The first five commits are Sahiru's and have already been reviewed in the relevant PR. In his PR, he created the backend for the Staff Grant Extension Feature and additionally created the backend notification system for emails.

This PR contains the backend notification system for in-system notifications. Since we currently do not have a way to persist notifications to display on the onTrack homepage, I created a notifications table and associated model. This table will store notifications for each user along with an associated message. This functionality can be extended in the future to store a boolean read value etc. The model has a relation with the user object so that we can access notifications for a specific user.

In terms of the Staff Grant Extension feature, a notification is created whenever an extension is granted successfully. This means we have a way of persisting the notification so that it doesn't just exist in memory but can be stored until it is read and deleted by the user. Additionally added tests to check that a notification is created when an extension is granted successfully.

Type of change

New feature (non-breaking change which adds functionality)

How Has This Been Tested?

To test this:

In your terminal, change directory to doubtfire-api - if you are in doubtfire-deploy, simply run the following

cd doubtfire-api

Run the following to apply pending migrations and update your database schema:

rails db:migrate

Run all test files using the following command:

rails test

Run the staff grant extension test using the following command:

rails test test/api/staff_grant_extension_test.rb

Additionally, if you want to test the notifications system integration with the front end, pull the front end code from PR:353 This means you can now view your notifications on the ontrack homepage.

Login as student (astudent, password)
Open a rails console
Create a new notification for user_id: 13 (a_student has a user_id of 13 in my db- it might not be the same for you)
Notification.create!(user_id: 13, message: "Test notification for student 13")
Navigate to your homepage and check that you have a new notification (red number on top of the bell)

Checklist:

My code follows the style guidelines of this project
I have performed a self-review of my own code
I have commented my code, particularly in hard-to-understand areas
I have made corresponding changes to the documentation if appropriate
My changes generate no new warnings
I have added tests that prove my fix is effective or that my feature works
I have created or extended unit tests to address my new additions
New and existing unit tests pass locally with my changes
Any dependent changes have been merged and published in downstream modules

If you have any questions, please contact @macite or @jakerenzella.

Enable staff to grant extensions to multiple students without formal requests. Reuse existing student extension logic through a new service for consistency. Supports flexible academic support and streamlines staff workflows. Relates to the OnTrack Staff Grant Extension design documentation.

…rpolated strings This aligns the test file with the string formatting convention used in the rest of the codebase. Single quotes are preferred when string interpolation is not needed, improving consistency. Reviewed as part of peer feedback.

Linked extension_comments_api (student-requested extensions) to use the shared ExtensionService, previously set up for staff-granted extensions. This refactor ensures both student and staff extension flows use the same logic, improving consistency and reducing duplication.

Implemented backend logic to send emails to tutor and student when extensions are granted. Also enable it so the front end can use the returned information from the api to display notifications.

A comment line change made in the staff grant extension feature branch that hasn't been updated here. Changing to keep the consistency.

SahiruWithanage

Hey Samindi !

I've reviewed the pr and it looks solid! The code is concise and follows the project's patterns well. I like how you've structured the database with a clean notification model connected to users and your API endpoints for fetching and deleting notifications are well-implemented.

A few minor suggestions that might be worth considering: adding some basic validations to the Notification model (e.g., presence/length for message), adding tests specifically for the notification API endpoints to ensure complete coverage and implementing pagination for the GET endpoint as notifications could accumulate over time (for an example someone might not click this at all for a long time and decides to click it only to get flooded with notifications).

I ran the Rails tests and no issues came up related to this implementation, which is a good sign but worth considering adding some test cases specific for this feature.

Overall, this provides a good foundation for the in-system notifications that accomplishes the goal of showing extension notifications to students. Great work!!

JoeMacl

Tested everything and it’s working great! Code is well structured and easy to follow.

As Sahiru mentioned, it’d be great to add some basic validations to the notification model like presence: true and maybe a character limit for the message. Also, adding pagination to the GET /notifications endpoint would help handle cases where students accumulate a lot of notifications over time.

Overall, great job! :)

aNebula · 2025-06-12T14:25:05Z

@samindiii LGTM. Please open an upstream pull request against 9.x branch in /doubtfire-lms/doubtfire-api.
Remember to include the description and link frontend PRs (if they are opened, and vice-versa)

- Add notifcation factory - Add unit tests for notifications - Only send first 20 notifications to front end - Have a max characters of 500

samindiii · 2025-08-10T07:49:35Z

Fixed up the code based on Sahiru and Joe's suggestions. Added a new test for the notifications API
rails test test/api/notifications_api_test.rb

…abot/bundler/websocket-driver-0.8.2 chore(deps): bump websocket-driver from 0.7.7 to 0.8.2

samindiii · 2025-05-18T07:32:03Z

Description

This PR contains backend changes from PR:60 by Sahiru. The first five commits are Sahiru's and have already been reviewed in the relevant PR. In his PR, he created the backend for the Staff Grant Extension Feature and additionally created the backend notification system for emails.

This PR contains the backend notification system for in-system notifications. Since we currently do not have a way to persist notifications to display on the onTrack homepage, I created a notifications table and associated model. This table will store notifications for each user along with an associated message. This functionality can be extended in the future to store a boolean read value etc. The model has a relation with the user object so that we can access notifications for a specific user.

In terms of the Staff Grant Extension feature, a notification is created whenever an extension is granted successfully. This means we have a way of persisting the notification so that it doesn't just exist in memory but can be stored until it is read and deleted by the user. Additionally added tests to check that a notification is created when an extension is granted successfully.

Type of change

New feature (non-breaking change which adds functionality)

How Has This Been Tested?

To test this:

In your terminal, change directory to doubtfire-api - if you are in doubtfire-deploy, simply run the following

cd doubtfire-api

Run the following to apply pending migrations and update your database schema:

rails db:migrate

Run all test files using the following command:

rails test

Run the staff grant extension test using the following command:

rails test test/api/staff_grant_extension_test.rb

Additionally, if you want to test the notifications system integration with the front end, pull the front end code from PR:353 This means you can now view your notifications on the ontrack homepage.

Login as student (astudent, password)
Open a rails console
Create a new notification for user_id: 13 (a_student has a user_id of 13 in my db- it might not be the same for you)
Notification.create!(user_id: 13, message: "Test notification for student 13")
Navigate to your homepage and check that you have a new notification (red number on top of the bell)

Checklist:

My code follows the style guidelines of this project
I have performed a self-review of my own code
I have commented my code, particularly in hard-to-understand areas
I have made corresponding changes to the documentation if appropriate
My changes generate no new warnings
I have added tests that prove my fix is effective or that my feature works
I have created or extended unit tests to address my new additions
New and existing unit tests pass locally with my changes
Any dependent changes have been merged and published in downstream modules

If you have any questions, please contact @macite or @jakerenzella.

Enable staff to grant extensions to multiple students without formal requests. Reuse existing student extension logic through a new service for consistency. Supports flexible academic support and streamlines staff workflows. Relates to the OnTrack Staff Grant Extension design documentation.

…rpolated strings This aligns the test file with the string formatting convention used in the rest of the codebase. Single quotes are preferred when string interpolation is not needed, improving consistency. Reviewed as part of peer feedback.

Linked extension_comments_api (student-requested extensions) to use the shared ExtensionService, previously set up for staff-granted extensions. This refactor ensures both student and staff extension flows use the same logic, improving consistency and reducing duplication.

Implemented backend logic to send emails to tutor and student when extensions are granted. Also enable it so the front end can use the returned information from the api to display notifications.

A comment line change made in the staff grant extension feature branch that hasn't been updated here. Changing to keep the consistency.

SahiruWithanage

Hey Samindi !

I've reviewed the pr and it looks solid! The code is concise and follows the project's patterns well. I like how you've structured the database with a clean notification model connected to users and your API endpoints for fetching and deleting notifications are well-implemented.

A few minor suggestions that might be worth considering: adding some basic validations to the Notification model (e.g., presence/length for message), adding tests specifically for the notification API endpoints to ensure complete coverage and implementing pagination for the GET endpoint as notifications could accumulate over time (for an example someone might not click this at all for a long time and decides to click it only to get flooded with notifications).

I ran the Rails tests and no issues came up related to this implementation, which is a good sign but worth considering adding some test cases specific for this feature.

Overall, this provides a good foundation for the in-system notifications that accomplishes the goal of showing extension notifications to students. Great work!!

JoeMacl

Tested everything and it’s working great! Code is well structured and easy to follow.

As Sahiru mentioned, it’d be great to add some basic validations to the notification model like presence: true and maybe a character limit for the message. Also, adding pagination to the GET /notifications endpoint would help handle cases where students accumulate a lot of notifications over time.

Overall, great job! :)

aNebula · 2025-06-12T14:25:05Z

@samindiii LGTM. Please open an upstream pull request against 9.x branch in /doubtfire-lms/doubtfire-api.
Remember to include the description and link frontend PRs (if they are opened, and vice-versa)

- Add notifcation factory - Add unit tests for notifications - Only send first 20 notifications to front end - Have a max characters of 500

samindiii · 2025-08-10T07:49:35Z

Fixed up the code based on Sahiru and Joe's suggestions. Added a new test for the notifications API
rails test test/api/notifications_api_test.rb

…abot/bundler/websocket-driver-0.8.2 chore(deps): bump websocket-driver from 0.7.7 to 0.8.2

samindiii · 2025-05-18T07:32:03Z

Description

This PR contains backend changes from PR:60 by Sahiru. The first five commits are Sahiru's and have already been reviewed in the relevant PR. In his PR, he created the backend for the Staff Grant Extension Feature and additionally created the backend notification system for emails.

This PR contains the backend notification system for in-system notifications. Since we currently do not have a way to persist notifications to display on the onTrack homepage, I created a notifications table and associated model. This table will store notifications for each user along with an associated message. This functionality can be extended in the future to store a boolean read value etc. The model has a relation with the user object so that we can access notifications for a specific user.

In terms of the Staff Grant Extension feature, a notification is created whenever an extension is granted successfully. This means we have a way of persisting the notification so that it doesn't just exist in memory but can be stored until it is read and deleted by the user. Additionally added tests to check that a notification is created when an extension is granted successfully.

Type of change

New feature (non-breaking change which adds functionality)

How Has This Been Tested?

To test this:

In your terminal, change directory to doubtfire-api - if you are in doubtfire-deploy, simply run the following

cd doubtfire-api

Run the following to apply pending migrations and update your database schema:

rails db:migrate

Run all test files using the following command:

rails test

Run the staff grant extension test using the following command:

rails test test/api/staff_grant_extension_test.rb

Additionally, if you want to test the notifications system integration with the front end, pull the front end code from PR:353 This means you can now view your notifications on the ontrack homepage.

Login as student (astudent, password)
Open a rails console
Create a new notification for user_id: 13 (a_student has a user_id of 13 in my db- it might not be the same for you)
Notification.create!(user_id: 13, message: "Test notification for student 13")
Navigate to your homepage and check that you have a new notification (red number on top of the bell)

Checklist:

My code follows the style guidelines of this project
I have performed a self-review of my own code
I have commented my code, particularly in hard-to-understand areas
I have made corresponding changes to the documentation if appropriate
My changes generate no new warnings
I have added tests that prove my fix is effective or that my feature works
I have created or extended unit tests to address my new additions
New and existing unit tests pass locally with my changes
Any dependent changes have been merged and published in downstream modules

If you have any questions, please contact @macite or @jakerenzella.

Enable staff to grant extensions to multiple students without formal requests. Reuse existing student extension logic through a new service for consistency. Supports flexible academic support and streamlines staff workflows. Relates to the OnTrack Staff Grant Extension design documentation.

…rpolated strings This aligns the test file with the string formatting convention used in the rest of the codebase. Single quotes are preferred when string interpolation is not needed, improving consistency. Reviewed as part of peer feedback.

Linked extension_comments_api (student-requested extensions) to use the shared ExtensionService, previously set up for staff-granted extensions. This refactor ensures both student and staff extension flows use the same logic, improving consistency and reducing duplication.

Implemented backend logic to send emails to tutor and student when extensions are granted. Also enable it so the front end can use the returned information from the api to display notifications.

A comment line change made in the staff grant extension feature branch that hasn't been updated here. Changing to keep the consistency.

SahiruWithanage

Hey Samindi !

I've reviewed the pr and it looks solid! The code is concise and follows the project's patterns well. I like how you've structured the database with a clean notification model connected to users and your API endpoints for fetching and deleting notifications are well-implemented.

A few minor suggestions that might be worth considering: adding some basic validations to the Notification model (e.g., presence/length for message), adding tests specifically for the notification API endpoints to ensure complete coverage and implementing pagination for the GET endpoint as notifications could accumulate over time (for an example someone might not click this at all for a long time and decides to click it only to get flooded with notifications).

I ran the Rails tests and no issues came up related to this implementation, which is a good sign but worth considering adding some test cases specific for this feature.

Overall, this provides a good foundation for the in-system notifications that accomplishes the goal of showing extension notifications to students. Great work!!

JoeMacl

Tested everything and it’s working great! Code is well structured and easy to follow.

As Sahiru mentioned, it’d be great to add some basic validations to the notification model like presence: true and maybe a character limit for the message. Also, adding pagination to the GET /notifications endpoint would help handle cases where students accumulate a lot of notifications over time.

Overall, great job! :)

aNebula · 2025-06-12T14:25:05Z

@samindiii LGTM. Please open an upstream pull request against 9.x branch in /doubtfire-lms/doubtfire-api.
Remember to include the description and link frontend PRs (if they are opened, and vice-versa)

- Add notifcation factory - Add unit tests for notifications - Only send first 20 notifications to front end - Have a max characters of 500

samindiii · 2025-08-10T07:49:35Z

Fixed up the code based on Sahiru and Joe's suggestions. Added a new test for the notifications API
rails test test/api/notifications_api_test.rb

…abot/bundler/websocket-driver-0.8.2 chore(deps): bump websocket-driver from 0.7.7 to 0.8.2

samindiii · 2025-05-18T07:32:03Z

Description

This PR contains backend changes from PR:60 by Sahiru. The first five commits are Sahiru's and have already been reviewed in the relevant PR. In his PR, he created the backend for the Staff Grant Extension Feature and additionally created the backend notification system for emails.

This PR contains the backend notification system for in-system notifications. Since we currently do not have a way to persist notifications to display on the onTrack homepage, I created a notifications table and associated model. This table will store notifications for each user along with an associated message. This functionality can be extended in the future to store a boolean read value etc. The model has a relation with the user object so that we can access notifications for a specific user.

In terms of the Staff Grant Extension feature, a notification is created whenever an extension is granted successfully. This means we have a way of persisting the notification so that it doesn't just exist in memory but can be stored until it is read and deleted by the user. Additionally added tests to check that a notification is created when an extension is granted successfully.

Type of change

New feature (non-breaking change which adds functionality)

How Has This Been Tested?

To test this:

In your terminal, change directory to doubtfire-api - if you are in doubtfire-deploy, simply run the following

cd doubtfire-api

Run the following to apply pending migrations and update your database schema:

rails db:migrate

Run all test files using the following command:

rails test

Run the staff grant extension test using the following command:

rails test test/api/staff_grant_extension_test.rb

Additionally, if you want to test the notifications system integration with the front end, pull the front end code from PR:353 This means you can now view your notifications on the ontrack homepage.

Login as student (astudent, password)
Open a rails console
Create a new notification for user_id: 13 (a_student has a user_id of 13 in my db- it might not be the same for you)
Notification.create!(user_id: 13, message: "Test notification for student 13")
Navigate to your homepage and check that you have a new notification (red number on top of the bell)

Checklist:

My code follows the style guidelines of this project
I have performed a self-review of my own code
I have commented my code, particularly in hard-to-understand areas
I have made corresponding changes to the documentation if appropriate
My changes generate no new warnings
I have added tests that prove my fix is effective or that my feature works
I have created or extended unit tests to address my new additions
New and existing unit tests pass locally with my changes
Any dependent changes have been merged and published in downstream modules

If you have any questions, please contact @macite or @jakerenzella.

Enable staff to grant extensions to multiple students without formal requests. Reuse existing student extension logic through a new service for consistency. Supports flexible academic support and streamlines staff workflows. Relates to the OnTrack Staff Grant Extension design documentation.

…rpolated strings This aligns the test file with the string formatting convention used in the rest of the codebase. Single quotes are preferred when string interpolation is not needed, improving consistency. Reviewed as part of peer feedback.

Linked extension_comments_api (student-requested extensions) to use the shared ExtensionService, previously set up for staff-granted extensions. This refactor ensures both student and staff extension flows use the same logic, improving consistency and reducing duplication.

Implemented backend logic to send emails to tutor and student when extensions are granted. Also enable it so the front end can use the returned information from the api to display notifications.

A comment line change made in the staff grant extension feature branch that hasn't been updated here. Changing to keep the consistency.

SahiruWithanage

Hey Samindi !

I've reviewed the pr and it looks solid! The code is concise and follows the project's patterns well. I like how you've structured the database with a clean notification model connected to users and your API endpoints for fetching and deleting notifications are well-implemented.

A few minor suggestions that might be worth considering: adding some basic validations to the Notification model (e.g., presence/length for message), adding tests specifically for the notification API endpoints to ensure complete coverage and implementing pagination for the GET endpoint as notifications could accumulate over time (for an example someone might not click this at all for a long time and decides to click it only to get flooded with notifications).

I ran the Rails tests and no issues came up related to this implementation, which is a good sign but worth considering adding some test cases specific for this feature.

Overall, this provides a good foundation for the in-system notifications that accomplishes the goal of showing extension notifications to students. Great work!!

JoeMacl

Tested everything and it’s working great! Code is well structured and easy to follow.

As Sahiru mentioned, it’d be great to add some basic validations to the notification model like presence: true and maybe a character limit for the message. Also, adding pagination to the GET /notifications endpoint would help handle cases where students accumulate a lot of notifications over time.

Overall, great job! :)

aNebula · 2025-06-12T14:25:05Z

@samindiii LGTM. Please open an upstream pull request against 9.x branch in /doubtfire-lms/doubtfire-api.
Remember to include the description and link frontend PRs (if they are opened, and vice-versa)

- Add notifcation factory - Add unit tests for notifications - Only send first 20 notifications to front end - Have a max characters of 500

samindiii · 2025-08-10T07:49:35Z

Fixed up the code based on Sahiru and Joe's suggestions. Added a new test for the notifications API
rails test test/api/notifications_api_test.rb

…abot/bundler/websocket-driver-0.8.2 chore(deps): bump websocket-driver from 0.7.7 to 0.8.2

samindiii · 2025-05-18T07:32:03Z

Description

This PR contains backend changes from PR:60 by Sahiru. The first five commits are Sahiru's and have already been reviewed in the relevant PR. In his PR, he created the backend for the Staff Grant Extension Feature and additionally created the backend notification system for emails.

This PR contains the backend notification system for in-system notifications. Since we currently do not have a way to persist notifications to display on the onTrack homepage, I created a notifications table and associated model. This table will store notifications for each user along with an associated message. This functionality can be extended in the future to store a boolean read value etc. The model has a relation with the user object so that we can access notifications for a specific user.

In terms of the Staff Grant Extension feature, a notification is created whenever an extension is granted successfully. This means we have a way of persisting the notification so that it doesn't just exist in memory but can be stored until it is read and deleted by the user. Additionally added tests to check that a notification is created when an extension is granted successfully.

Type of change

New feature (non-breaking change which adds functionality)

How Has This Been Tested?

To test this:

In your terminal, change directory to doubtfire-api - if you are in doubtfire-deploy, simply run the following

cd doubtfire-api

Run the following to apply pending migrations and update your database schema:

rails db:migrate

Run all test files using the following command:

rails test

Run the staff grant extension test using the following command:

rails test test/api/staff_grant_extension_test.rb

Additionally, if you want to test the notifications system integration with the front end, pull the front end code from PR:353 This means you can now view your notifications on the ontrack homepage.

Login as student (astudent, password)
Open a rails console
Create a new notification for user_id: 13 (a_student has a user_id of 13 in my db- it might not be the same for you)
Notification.create!(user_id: 13, message: "Test notification for student 13")
Navigate to your homepage and check that you have a new notification (red number on top of the bell)

Checklist:

My code follows the style guidelines of this project
I have performed a self-review of my own code
I have commented my code, particularly in hard-to-understand areas
I have made corresponding changes to the documentation if appropriate
My changes generate no new warnings
I have added tests that prove my fix is effective or that my feature works
I have created or extended unit tests to address my new additions
New and existing unit tests pass locally with my changes
Any dependent changes have been merged and published in downstream modules

If you have any questions, please contact @macite or @jakerenzella.

Enable staff to grant extensions to multiple students without formal requests. Reuse existing student extension logic through a new service for consistency. Supports flexible academic support and streamlines staff workflows. Relates to the OnTrack Staff Grant Extension design documentation.

…rpolated strings This aligns the test file with the string formatting convention used in the rest of the codebase. Single quotes are preferred when string interpolation is not needed, improving consistency. Reviewed as part of peer feedback.

Linked extension_comments_api (student-requested extensions) to use the shared ExtensionService, previously set up for staff-granted extensions. This refactor ensures both student and staff extension flows use the same logic, improving consistency and reducing duplication.

Implemented backend logic to send emails to tutor and student when extensions are granted. Also enable it so the front end can use the returned information from the api to display notifications.

A comment line change made in the staff grant extension feature branch that hasn't been updated here. Changing to keep the consistency.

SahiruWithanage

Hey Samindi !

I've reviewed the pr and it looks solid! The code is concise and follows the project's patterns well. I like how you've structured the database with a clean notification model connected to users and your API endpoints for fetching and deleting notifications are well-implemented.

A few minor suggestions that might be worth considering: adding some basic validations to the Notification model (e.g., presence/length for message), adding tests specifically for the notification API endpoints to ensure complete coverage and implementing pagination for the GET endpoint as notifications could accumulate over time (for an example someone might not click this at all for a long time and decides to click it only to get flooded with notifications).

I ran the Rails tests and no issues came up related to this implementation, which is a good sign but worth considering adding some test cases specific for this feature.

Overall, this provides a good foundation for the in-system notifications that accomplishes the goal of showing extension notifications to students. Great work!!

JoeMacl

Tested everything and it’s working great! Code is well structured and easy to follow.

As Sahiru mentioned, it’d be great to add some basic validations to the notification model like presence: true and maybe a character limit for the message. Also, adding pagination to the GET /notifications endpoint would help handle cases where students accumulate a lot of notifications over time.

Overall, great job! :)

aNebula · 2025-06-12T14:25:05Z

@samindiii LGTM. Please open an upstream pull request against 9.x branch in /doubtfire-lms/doubtfire-api.
Remember to include the description and link frontend PRs (if they are opened, and vice-versa)

- Add notifcation factory - Add unit tests for notifications - Only send first 20 notifications to front end - Have a max characters of 500

samindiii · 2025-08-10T07:49:35Z

Fixed up the code based on Sahiru and Joe's suggestions. Added a new test for the notifications API
rails test test/api/notifications_api_test.rb

…abot/bundler/websocket-driver-0.8.2 chore(deps): bump websocket-driver from 0.7.7 to 0.8.2

samindiii · 2025-05-18T07:32:03Z

Description

This PR contains backend changes from PR:60 by Sahiru. The first five commits are Sahiru's and have already been reviewed in the relevant PR. In his PR, he created the backend for the Staff Grant Extension Feature and additionally created the backend notification system for emails.

This PR contains the backend notification system for in-system notifications. Since we currently do not have a way to persist notifications to display on the onTrack homepage, I created a notifications table and associated model. This table will store notifications for each user along with an associated message. This functionality can be extended in the future to store a boolean read value etc. The model has a relation with the user object so that we can access notifications for a specific user.

In terms of the Staff Grant Extension feature, a notification is created whenever an extension is granted successfully. This means we have a way of persisting the notification so that it doesn't just exist in memory but can be stored until it is read and deleted by the user. Additionally added tests to check that a notification is created when an extension is granted successfully.

Type of change

New feature (non-breaking change which adds functionality)

How Has This Been Tested?

To test this:

In your terminal, change directory to doubtfire-api - if you are in doubtfire-deploy, simply run the following

cd doubtfire-api

Run the following to apply pending migrations and update your database schema:

rails db:migrate

Run all test files using the following command:

rails test

Run the staff grant extension test using the following command:

rails test test/api/staff_grant_extension_test.rb

Additionally, if you want to test the notifications system integration with the front end, pull the front end code from PR:353 This means you can now view your notifications on the ontrack homepage.

Login as student (astudent, password)
Open a rails console
Create a new notification for user_id: 13 (a_student has a user_id of 13 in my db- it might not be the same for you)
Notification.create!(user_id: 13, message: "Test notification for student 13")
Navigate to your homepage and check that you have a new notification (red number on top of the bell)

Checklist:

My code follows the style guidelines of this project
I have performed a self-review of my own code
I have commented my code, particularly in hard-to-understand areas
I have made corresponding changes to the documentation if appropriate
My changes generate no new warnings
I have added tests that prove my fix is effective or that my feature works
I have created or extended unit tests to address my new additions
New and existing unit tests pass locally with my changes
Any dependent changes have been merged and published in downstream modules

If you have any questions, please contact @macite or @jakerenzella.

Enable staff to grant extensions to multiple students without formal requests. Reuse existing student extension logic through a new service for consistency. Supports flexible academic support and streamlines staff workflows. Relates to the OnTrack Staff Grant Extension design documentation.

…rpolated strings This aligns the test file with the string formatting convention used in the rest of the codebase. Single quotes are preferred when string interpolation is not needed, improving consistency. Reviewed as part of peer feedback.

Linked extension_comments_api (student-requested extensions) to use the shared ExtensionService, previously set up for staff-granted extensions. This refactor ensures both student and staff extension flows use the same logic, improving consistency and reducing duplication.

Implemented backend logic to send emails to tutor and student when extensions are granted. Also enable it so the front end can use the returned information from the api to display notifications.

A comment line change made in the staff grant extension feature branch that hasn't been updated here. Changing to keep the consistency.

SahiruWithanage

Hey Samindi !

I've reviewed the pr and it looks solid! The code is concise and follows the project's patterns well. I like how you've structured the database with a clean notification model connected to users and your API endpoints for fetching and deleting notifications are well-implemented.

A few minor suggestions that might be worth considering: adding some basic validations to the Notification model (e.g., presence/length for message), adding tests specifically for the notification API endpoints to ensure complete coverage and implementing pagination for the GET endpoint as notifications could accumulate over time (for an example someone might not click this at all for a long time and decides to click it only to get flooded with notifications).

I ran the Rails tests and no issues came up related to this implementation, which is a good sign but worth considering adding some test cases specific for this feature.

Overall, this provides a good foundation for the in-system notifications that accomplishes the goal of showing extension notifications to students. Great work!!

JoeMacl

Tested everything and it’s working great! Code is well structured and easy to follow.

As Sahiru mentioned, it’d be great to add some basic validations to the notification model like presence: true and maybe a character limit for the message. Also, adding pagination to the GET /notifications endpoint would help handle cases where students accumulate a lot of notifications over time.

Overall, great job! :)

aNebula · 2025-06-12T14:25:05Z

@samindiii LGTM. Please open an upstream pull request against 9.x branch in /doubtfire-lms/doubtfire-api.
Remember to include the description and link frontend PRs (if they are opened, and vice-versa)

- Add notifcation factory - Add unit tests for notifications - Only send first 20 notifications to front end - Have a max characters of 500

samindiii · 2025-08-10T07:49:35Z

Fixed up the code based on Sahiru and Joe's suggestions. Added a new test for the notifications API
rails test test/api/notifications_api_test.rb

…abot/bundler/websocket-driver-0.8.2 chore(deps): bump websocket-driver from 0.7.7 to 0.8.2

Sahiru Withanageand others added 8 commits May 11, 2025 14:05

feat(notifications): send notifications when extensions are granted
c454932
Implemented backend logic to send emails to tutor and student when extensions are granted. Also enable it so the front end can use the returned information from the api to display notifications.

Make a comment line change
35b2eab
A comment line change made in the staff grant extension feature branch that hasn't been updated here. Changing to keep the consistency.

Add notification table, model and define relation with user
298460d

Define notification api's to GET and DELETE notification by id
a984ce3

Create in-system notifications for students with successfull extensions
bef3055

samindiii mentioned this pull request May 18, 2025
Add in-system notifications for students thoth-tech/doubtfire-web#353
Open
9 tasks

samindiii changed the title ~~Feature/extension notification backend~~Add Notification Table, Model for in-system notificationsMay 18, 2025

samindiii changed the title ~~Add Notification Table, Model for in-system notifications~~Add notification table and model for in-system notificationsMay 18, 2025

SahiruWithanage approved these changes May 21, 2025
View reviewed changes

JoeMacl approved these changes May 21, 2025
View reviewed changes

Fix review comments
7b2fb32
- Add notifcation factory - Add unit tests for notifications - Only send first 20 notifications to front end - Have a max characters of 500

SteveDala mentioned this pull request Jan 22, 2026
feat(SGE): API Rebase to 10.0.x #82
Closed
11 tasks

Thirus224849242 pushed a commit to Thirus224849242/doubtfire-api that referenced this pull request Aug 25, 2026
Merge pull requestthoth-tech#69from ontrack-features-t2-2026/depend…
dd0011f
…abot/bundler/websocket-driver-0.8.2 chore(deps): bump websocket-driver from 0.7.7 to 0.8.2