You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This PR has an implementation for "Notification System" feature which allows users to initiate/receive notification whenever project(application) or engine related any activity occurs.
As User story 1 & User story 2, 3 this implementation has covered five use cases for notification feature.
1. When new user is added to the project
2. When user requests access for the project
3. When user’s role changes
4. When project member approves new user request or permission change
5. When project member declines new user request or permission change
6. When new user is added to the engine
7. When user requests access for the engine
8. When user’s role changes
9. When engine member approves new user request or permission change
10. When engine member declines new user request or permission change
As per the use cases, we have called notification utility method addNotification() across different ProjectUtility as well as EngineUtility methods.
Changes Made
Created new table NOTIFICATION table in Security DB to store all the notifications.
Created a separate utility class for notifications -> SecurityNotificationUtils : It contains all the utility methods to perform operations related to notifications.
Created PollingNotifications Reactor: This reactor returns number of new notifications for logged in user from Notification database table.
Created GetNotifications Reactor: This reactor returns all the notifications for the logged in user from Notification database table. (New Notifications+ Read Notifications+ Unread Notifications)
Created UpdateReadNotifications Reactor: This reactor is responsible to update “Read Notifications” in Notification database table. This reactor accepts notificationId & updates ‘Read’ status of the notification.
Created DeleteNotifications Reactor: Using logged in user, this reactor deletes single or multiple notification from the Notification database table for that given user.
NOTIFICATION table structure :
How to Test
To test notification feature, we need front-end UI, here is the front-end branch - link
This PR has an implementation for "Notification System" feature which allows users to initiate/receive notification whenever project(application) or engine related any activity occurs.
As User story 1 & User story 2, 3 this implementation has covered five use cases for notification feature.
1. When new user is added to the project
2. When user requests access for the project
3. When user’s role changes
4. When project member approves new user request or permission change
5. When project member declines new user request or permission change
6. When new user is added to the engine
7. When user requests access for the engine
8. When user’s role changes
9. When engine member approves new user request or permission change
10. When engine member declines new user request or permission change
As per the use cases, we have called notification utility method addNotification() across different ProjectUtility as well as EngineUtility methods.
Changes Made
Created new table NOTIFICATION table in Security DB to store all the notifications.
Created a separate utility class for notifications -> SecurityNotificationUtils : It contains all the utility methods to perform operations related to notifications.
Created PollingNotifications Reactor: This reactor returns number of new notifications for logged in user from Notification database table.
Created GetNotifications Reactor: This reactor returns all the notifications for the logged in user from Notification database table. (New Notifications+ Read Notifications+ Unread Notifications)
Created UpdateReadNotifications Reactor: This reactor is responsible to update “Read Notifications” in Notification database table. This reactor accepts notificationId & updates ‘Read’ status of the notification.
Created DeleteNotifications Reactor: Using logged in user, this reactor deletes single or multiple notification from the Notification database table for that given user.
NOTIFICATION table structure :
How to Test
To test notification feature, we need front-end UI, here is the front-end branch - link
In denyEngineUserAccessRequests, the code fetches deniedUserDetails per requestId but then indexes the list with i, which may not be 0 and can cause IndexOutOfBounds or mismatched user/permission. Use index 0 or iterate over the returned list safely.
The NOTIFICATION table creation arrays define 18 columns, but defaultValues only contains 15 entries. Although not directly used in createTableIfNotExists, this mismatch suggests potential maintenance errors; ensure schema/defaults alignment.
addNotification inserts null for MESSAGE and READAT and assumes member has a login; member.getLogins().get(0) may throw if empty. Guard against empty logins and consider non-null defaults for text fields.
The defaultValues array length does not match colNames (18 vs 16), which can cause SQL creation failures or misaligned defaults. Provide a default for each column or pass the correct number of defaults to the table creation to avoid runtime errors.
Why: Correctly identifies that defaultValues has fewer entries than colNames (16 vs 18), which can break table creation; the proposed fix aligns lengths and prevents runtime SQL issues.
Medium
Prevent out-of-bounds on detail list
Indexing deniedUserDetails by i assumes each query returns a list at least of size i+1, which may cause IndexOutOfBounds. Use the first (only) row or iterate the returned list independently to avoid runtime exceptions.
Why: Using deniedUserDetails.get(i) ties the inner list to the outer loop index and can cause IndexOutOfBounds; guarding and using the first row is safer and likely correct.
Medium
Guard against empty query results
Similar to the project path, indexing deniedUserDetails with i risks IndexOutOfBounds and null pointer issues. Safely read the first returned row (or iterate that list) and guard against empty results before sending notifications.
Why: Mirrors the same indexing risk as the project path; adding null/empty checks and indexing the first element avoids exceptions and improves robustness.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Description
This PR has an implementation for "Notification System" feature which allows users to initiate/receive notification whenever project(application) or engine related any activity occurs.
As User story 1 & User story 2, 3 this implementation has covered five use cases for notification feature.
1. When new user is added to the project
2. When user requests access for the project
3. When user’s role changes
4. When project member approves new user request or permission change
5. When project member declines new user request or permission change
6. When new user is added to the engine
7. When user requests access for the engine
8. When user’s role changes
9. When engine member approves new user request or permission change
10. When engine member declines new user request or permission change
As per the use cases, we have called notification utility method
addNotification()across different ProjectUtility as well as EngineUtility methods.Changes Made
Created new table
NOTIFICATIONtable in Security DB to store all the notifications.Created a separate utility class for notifications ->
SecurityNotificationUtils: It contains all the utility methods to perform operations related to notifications.Created
PollingNotifications Reactor: This reactor returns number of new notifications for logged in user fromNotificationdatabase table.Created
GetNotifications Reactor: This reactor returns all the notifications for the logged in user fromNotificationdatabase table. (New Notifications+ Read Notifications+ Unread Notifications)Created
UpdateReadNotifications Reactor: This reactor is responsible to update “Read Notifications” inNotificationdatabase table. This reactor acceptsnotificationId& updates ‘Read’ status of the notification.Created
DeleteNotifications Reactor: Using logged in user, this reactor deletes single or multiple notification from theNotificationdatabase table for that given user.NOTIFICATION table structure :
How to Test
485259853-426eb3a0-26e4-4989-8576-fc8b84dc11cd.mp4