Yashwanth_Backend_for_permission_log_table

[yashwanth170]

Description

The permission change log table only logs changes made to role, so I have added additional features to log permission changes made to individual account. Now the table shows latest logs of changes made to both individual and role

Related PRS (if any):

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

Main changes explained:

• Developed a new MongoDB model to store logs of individual permission changes.
• Implemented a new controller class with a POST method to save data into the MongoDB model and a GET API to retrieve logs from both UserPermissionChangeLog and PermissionChangeLog, sorting them accordingly.
  …

How to test:

1. check into current branch, and check into frontend branch Yashwanth_individual_permission_change_show
2. do npm install and ... to run this PR locally
3. Clear site data/cache
4. log as admin user
5. go to dashboard→ Other Links → Permission Management → Make changes to a role or individual and verify that the table updates accordingly.

Screenshots or videos of changes:

Note:

Test the updated implementation across different user types and let me know if I missed any expected conventions or if you have additional suggestions. I’ve also resolved an existing issue where submitting without adding or removing any permissions no longer logs duplicate entries for both role and user permissions.

[nathanah]

The POST request should not have it's own API so that the updates are atomic. The GET request should be updating/replacing the original GET request.

[nathanah]

Suggested change

userProfileRouter.post('/logPermissionChanges', logUserPermissionController.logPermissionChanges);

You shouldn't be able to edit history without making the edits. Instead, call logPermissionChanges from wherever the permissions are changed (putUserProfile() I think?). That unites both API calls into one and can guarantee that the updates are atomic.

Uniting the API calls makes it so devs testing with Postman don't have to make multiple API calls to make the history accurate and ensures that they can't make API calls to give false update history. You currently don't check for requestor permissions in logPermissionChanges, so anyone could add false information with this API using something like Postman.

[nathanah]

I would avoid doing the added/removed/existing permission logic on the frontend. Only requesting newPermissions from the frontend should be enough to derive the info on the backend.

Can find 'existingPermissions'/'oldPermissions' from the DB to ensure the info is accurate.

addedPermissions = newPermissions.filter(x=> !oldPermissions.contains(x));
removedPermissions = oldPermissions.filter(x => !newPermissions.contains(x));

[nathanah]

Is this checking for permission to view the history? I think Admins might also want to see the history? not sure.
Could use await hasPermission(req.body.requestor, 'getPermissionHistory') or something (could use an existing permission or create a new one). There shouldn't be hardcoded references to specific roles if avoidable.

[nathanah]

I see that's just copied from getPermissionChangeLogs... I guess it is only Owners then. Would've been easier to find if this was modifying that file instead of creating a new file.

[one-community]

Thank you all, merging!