Anthony/added permission changes for default permissions of user

[AnthonyWeathers]

Description

Modified logUserPermissionChangeByAccount.js to work with frontend PR#3600 and update the permission change log table in Permissions Management for Owner users

Related PRS (if any):

This backend PR is related to the PR#3600 frontend PR.
To test this backend PR you need to checkout the PR#3600 frontend PR.
…

Main changes explained:

• Updated logUserPermissionChangeByAccount.js to utilize removed default role permissions for a user, and have it saved accordingly, so in the log table, it will show permission changes for added permissions the user would normally not have due to their role, and also changes to permissions they'd have by default, because of their role. Also accounts for role changes of a user, and resets their permissions to the role, removing or adding permissions accordingly.

…

How to test:

1. check into current branch and PR#3600 frontend PR
2. do npm install, then npm run build, and lastly npm start to run this PR locally
3. Clear site data/cache
4. log as Owner user
5. go to dashboard→ Other Links→ Permissions Management→Manage User Permissions
6. Select a user and modify their permissions, and save changes
7. Await for the log table to be updated and verify if the permissions you added appeared in Permissions Added, and permissions you removed, appear in Permissions Removed columns respectively, and if you change some in a follow up, only the ones you changed appear.
8. Go to the user's profile, and change their role, then return to Manage User Permissions, and verify that a new change log appears indicating the user's role was changed.
9. Go to Other Links→ User Management
10. Click icon to edit role field, and pick a user or multiple, you can use Anthony Volunteer, Anthony Test, and Anthony Test2 freely if you need, then save the role changes.
11. Return to Permissions Management, and see if that creates change logs reflecting the role changes for the users you choose.

Note:

1. If a user you're changing, already had permissions removed or added prior to this PR pair, indicator by a star icon listed in the frontend PR, then changes to those permissions might not be saved properly. I tried addressing it, so hopefully it does work, but let me know if anything unexpected occurs though.

2. There's a current bug in User Management, if you make changes to a user, the array containing that change, will retain all changes you make, whether you changed the role of a user repeatedly or not, same for if you saved some changes, the array will still keep them until you refresh the page or leave it and return. If you make multiple changes without refreshing or leaving the page, then you may/will see repeated change logs for a user if you've changed their role more than once, or if you saved the change, then modified the role of another user, or a different field of the user.

[nathanah]

Since changedPermissions is defined as const changedPermissions = [...Permissions, ...removedPermissions];, it doesn't distinguish between if the edited permissions are added or removed from the role permissions. This can be interpreted by cross-referencing the role permissions. Either consider them added if not found in the role permissions, or removed if they are found in the role permissions.
However, this cross-reference check could be broken if the user's role changes (along with their role permissions) or if the role's permissions change. A role change would thus break our ability to interpret old logs. I think it needs to have removedRolePermissions as a labeled entry to keep this context.

[nathanah]

Or it's cross-referenced with the permissionsAdded and permissionsRemoved fields of all previous entries for this user?

[nathanah]

Adding/removing a permission to a user, then mirroring that change to the role will keep showing that change as new with every update.

Suggested change

	permissionsRemoved = [
	...removedPermissions.filter((item) => !docPermissions.includes(item)), //saves new removed defaults
	...docPermissions.filter(
	// saves changes of only removed non-default role permissions for user
	(item) => !defaultPermissions.includes(item) && !Permissions.includes(item),
	),
	];
	permissionsAdded = [
	...Permissions.filter((item) => !docPermissions.includes(item)), // saves new added permissions
	...docPermissions.filter(
	// saves changes of only removed default permissions being added back
	(item) => defaultPermissions.includes(item) && !removedPermissions.includes(item),
	),
	];
	permissionsRemoved = [
	...removedPermissions.filter((item) => !prevRemovedPermissions.includes(item)), //saves new removed defaults
	...prevAddedPermissions.filter((item) =>!Permissions.includes(item)), //removed user permissions
	];
	permissionsAdded = [
	...Permissions.filter((item) => !prevAddedPermissions.includes(item)), // saves new added permissions
	...prevRemovedPermissions.filter((item) => !removedPermissions.includes(item)), //removed permissions added back
	];

[AnthonyWeathers]

I understand that concern, I'll have to take a look into how changing the role of a user with added permissions or removed role permissions affects things with the logs before I can see if it causes issues, and then try implementing the changes you suggested to see if that helps resolve it.

Currently though, when I try modifying the role of my alt manager account on the development live app or locally, I receive an error. This is when I open the profile of my alt, while on my owner account, scroll to their Role, open the role menu and select administrator or volunteer, just to try changing for the changes in permissions, and receive the error I shared below. Does this occur for you? Otherwise if its just my end, I am unsure how to resolve it so I can test the potential issue with role changes with my code. Thank you for bringing up the potential issues though!

[AnthonyWeathers]

Nevermind, it was an error that occurred during work on another PR, after deleting the incorrect data, I was able to change the role of my alt to test your concerns. You are right that role changes does impact the change log, and your suggested code to handle permissions added and remove does seem better, but in the case of prevAddedPermissions, if we add a permission, say 'Edit Task' to a user, then updated their role to be higher, which includes 'Edit Task' as a default, if a new change log is made for the user, then ...prevAddedPermissions.filter((item) =>!Permissions.includes(item)) in setting permissionsRemoved would be triggered, as I checked, and on the frontend ui for the permission list, through console logs, when I checked the permissions of my alt, its permissions were set to the role's default, so the respective permissions and removedPermissions become blank at first. So with 'Edit Task', it would no be in Permissions if it becomes a default permission due to role, thus being counted as one to be listed under permissionsRemoved. So I should also include a check to see if the item in question, is listed in the role's default list?

[AnthonyWeathers]

@nathanah Been a bit, but I've revised my code, and added a removedRolePermissions field to the UserPermissionChangeLog schema, so could you check it out and verify if my code would work fine? I tested it using my alt, and it seemed to work with role changes while still performing the original job with just changing permissions. I could record a demo to showcase it if needed.

[nathanah]

Sorry for the delay. LGTM

[Anusha-Gali]

Hi Anthony,

I have reviewed your PR locally and have mentioned my comments in frontend: OneCommunityGlobal/HighestGoodNetworkApp#3600 (review)

[sayali-2308]

PR #1447 (Anthony - Added PermissionChanges For DefaultPermissions Of User): Backend #1447: Reviewed in conjunction with frontend PR #3600
Checked out backend branch Anthony/Added-PermissionChanges-For-DefaultPermissions-Of-User, ran npm install, started backend server. Tested with frontend branch.

CRITICAL BACKEND ISSUES:

1. Permission Update Endpoint - 404 Error:

• Frontend sends request to save permission changes
• Backend returns: "AxiosError: Request failed with status code 404"
• API endpoint for updating user permissions appears to be missing or incorrectly configured
• Prevents any permission modifications from being saved
• This is a critical backend failure blocking core functionality

2. Role Change Endpoint - Save Error:

• Frontend sends request to save user role change (Volunteer → Manager)
• Backend returns error: "Sorry an error occured while trying to save"
• Role changes cannot be saved
• Prevents creation of role change log entries in Permission Change Logs Table
• Critical backend failure

Backend Endpoints to Verify:

• Permission update endpoint (currently returning 404)
• Role change/update endpoint (currently failing with error)
• Permission Change Log creation endpoint (cannot test due to save failures)
• User profile update endpoint (failing when role is changed)

Required Changes:

1. Fix permission update API endpoint - resolve 404 error
2. Fix role change save functionality - resolve save error
3. Verify Permission Change Log entries are created correctly when permissions/roles are modified
4. Ensure all API responses return proper error messages and status codes
5. Test complete flow: modify permission → save → create log entry → display in table

[sonarqubecloud]

Quality Gate passed

Issues
1 New issue
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[AmaanSyed09]

Tested backend PR #1447 together with frontend PR #3600.

I observed the same issue documented in my detailed review on frontend PR #3600. Role changes performed through User Management are saved successfully, but no corresponding Permission Change Log entry is created in Permissions Management.

Since the failure reproduces with this backend/frontend PR pair and affects functionality described in the PR requirements, I am requesting changes here as well. Please refer to my detailed review comments on frontend PR #3600 for reproduction steps, expected behavior, and testing details.

[kzou55]

Hi Anthony,

I ran the current branch alongside the associated frontend branch.

I verified that the functionality implemented works. Refer to the review from the FrontEnd PR

Issues

• Got this notification and caused me to log out even though the user I changed wasn't the one I was on? Is this suppose to happen? And when I first logged in to my Owner Account, I got that notification and got signed out. Although both of these occurrences aren't consistently repeatable.
  

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[akv-iu]

Test Summary

Tested backend PR #1447 with frontend PR #3600 together.

Environment

• Checked out backend branch: Anthony/Added-PermissionChanges-For-DefaultPermissions-Of-User
• Checked out frontend branch: Anthony/Use-PemissionsData-To-Indicate-PermissionsBeyond-UserRole-DefaultPermissions

Issue

• When changing the role from Creator to Administrator, log entries in all columns are correct, but the Permissions Removed column shows "See default Administrator role permissions," whereas it should show "See default Creator role permissions.

[iAbhi001]

Thanks for testing! For role changes, the text in the Permissions Removed column displays "See default Administrator role permissions" because Administrator is the user's target/new role once saved.

Note: I'm unable to see the images/screenshots attached to your review comment log. If there's extra detail in those images, please let me know!

[sawantgayatri19]

Thanks for testing and reviewing!

Regarding the role change log issue (akv-iu's review), when a user's role is updated (e.g., from Creator to Administrator), the Permissions Removed column incorrectly displays the target/new role's message ("See default Administrator role permissions") because it pulls the new role context instead of the previous one.

What needs to change:

The backend logic handling role modifications needs to reference and display the previous role's context (e.g., "See default Creator role permissions") in the Permissions Removed column rather than defaulting to the newly assigned role.

[AdiDubbs]

The permission change log work is a genuine improvement and the model additions are clean — both new fields are additive with defaults.

The main issue is on the frontend (#3600): the new permissions PATCH in UserProfile.jsx runs on every profile save rather than only on role changes, and its reason is hardcoded to "Role Changed to X." Because this backend only skips logging when reason doesn't contain "Role Changed", any profile edit writes a false role-change entry into the audit log.

On this PR: reason.includes(...) isn't guarded the way the array inputs are, and because the error is swallowed by two layers of try/catch the result is a silently missing audit entry rather than a visible failure.

This branch is 204 commits behind development (frontend 831), so both need a rebase before this can be tested end to end.

Related frontend review posted on #3600.

[AdiDubbs]

reason.includes('Role Changed') will throw if a request doesn't include reason — every array input here goes through checkPermissionArray, but the string doesn't get the same treatment. The frontend guards it everywhere it reads it (reason?.includes(...), and a 'Permissions changed.' fallback for older logs), so it clearly can be absent.

The failure is quiet, which is the concerning part: the throw happens before logEntry.save(), gets caught here and again in permissionService.updatePermissions, so the permission update succeeds and the audit entry is just silently missing. reason = '' in the destructure, or reason?.includes(...), would cover it.

[AnthonyWeathers]

Thanks for testing and reviewing!

Regarding the role change log issue (akv-iu's review), when a user's role is updated (e.g., from Creator to Administrator), the Permissions Removed column incorrectly displays the target/new role's message ("See default Administrator role permissions") because it pulls the new role context instead of the previous one.

What needs to change:

The backend logic handling role modifications needs to reference and display the previous role's context (e.g., "See default Creator role permissions") in the Permissions Removed column rather than defaulting to the newly assigned role.

I see, that does explain the reasoning behind the request, but could I inquire for the reasoning of why for the Permissions Removed column, should be the previous role of the user rather than the their role? I'm interested why only the removed column, while the added column is allowed to use the newly assigned role.

[Adit0717]

Tested the PR on the relevant backend and frontend branches. Found an issue:

In "Manage User Permissions," if I make a change and then undo it (or just click "Reset to Default") - so nothing actually changed - the app still makes a backend call to update the user's permissions. This call shouldn't happen when there's no actual change to save.

[linlin-husky]

Hi AnthonyWeathers. I have checked the backend 1447 with front end 3660 and found the below issues.

1. Permission Log Overwrite on Role Changes (Critical)

In src/utilities/logUserPermissionChangeByAccount.js:
When roleChanged evaluates to true, assigning Permissions and removedPermissions directly to permissionsAdded and permissionsRemoved skips diffing against the user's prior state. Any unchanged custom permissions that existed prior to the role change are incorrectly logged as newly modified.

2. Full-State Dump on Missing Prior Logs

In the else fallback branch, if no prior log document exists (!document), the full permission set is recorded directly into permissionsAdded and permissionsRemoved, generating false bulk audit logs for first-time entries.

pls check the below image

This is the reason why when I checked the front end 3600, when I changed the permission for some role, the history log does not record it. I added in front end 3600 reviews.

[DeMoliT1on]

LGTM! The core functionality for the backend PR#1447 is working properly, handling the permission change logs, default role checks, and user profile/management role updates correctly. Minor UI bug reviewed in the related frontend PR#3600

Approved!

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
95.5% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud