Reason for deactivating and reactivating a user not showing

[prinzab]

Bug description:
Reason for deactivating and reactivating a user not showing in user audit

Steps to reproduce:

1. Login as an admin (j.campbell)
2. Go to teams
3. Click on the 3 dot menu for any user
4. Click on deactivate
5. Select a reason for deactivating the user
6. Click on deactivate to deactivate the user
7. Observe the status change
8. Click on the 3 dot menu again
9. Click on reactivate
10. Select a reason
11. Click on the Reactivate button
12. Observe the status change
13. Click on the name of the admin that performed the actions (j.campbell) to open the audit page
14. Validate system actions for both Deactivated user and Reactivated user by clicking on their respective links
15. Observe

Actual result:

1. The deactivated user and the reason for deactivating the user does not show on the modal
2. The reactivated user and the reason for reactivating the user does not show on the modal

Expected result:

1. The deactivated user and the reason for deactivating the user should show on the modal
2. The reactivated user and the reason for reactivating the user should show on the modal

Environment:
https://login.farajaland-qa.opencrvs.org/

Version:
v1.5.0

Deactivated user

Reactivated user

Tech tasks

• Ensure "reason" is written to deactivation and reactivation events properly here.
• When reading user audit log events, in GraphQL schema, ensure one of the result types is one for these event types. Needs to include the reason field. Relevant code here.
• Make sure the reason field is properly rendered in the UI modal

[tahmidrahman-dsi]

@rikukissa @naftis @Zangetsu101 audit logs of a National System Admin or any other user are fetched from metrics. The reason & comment are not there. They are inside the auditHistories of the corresponding users on whom the specific audit actions occurred. Currently, I can not see any relation between these two (metrics and user-mgnt) actions. Do you know how we can do this?
cc: @Nil20

[euanmillar]

@rikukissa awaiting a technical design

[rikukissa]

I think it's best if we improve the system in regards to audit events overall. This means moving the events out from influxdb and into under users.auditHistory which would then include both actions performed by you and actions performed to your user.

The reason I'm saying this is security and traceability. Audit actions are 1st class data that we cannot lose but InfluxDB really is designed to be a 2nd tier database where we accept a bit more risk of data loss (no replication for instance). This is because 100% of audit data should be possible to regenerate from primary databases if need be.

I will also consider a patch solution and add a proper design. At the moment if seems however that no matter how this is done, we still need a migration.

Problem with all the following solutions is we cannot reliably match history events in influxdb to the ones in user-mgnt.users.auditHistory

Option 1. Move all audit events to user management database

• Improves storage reliability for audit event data
• Simplifies querying the data as user details and user audit are always fetched simultaneously. Improved query speed
• Needs migration to move data from InfluxDB to MongoDB

Option 2. Read user-mgnt.users.auditHistory database from metrics service to find the correct audit event and reason

• Option 2.1. Direct database read from Metrics service (find auditHistory items where .auditedBy is userId

  • Direct database access from metrics to user-mgnt.users cannot be made because of security concerns

• Option 2.2. Endpoint in user-mgnt service to get all audit history items where .auditedBy is userId

  • Currently no way of matching an event in auditHistory to one in metrics. Shared ID would fix this.
  • Would only work properly from deployment of 1.5 onwards but migration to both databases still required to assign ids

Option 3. Duplicate reason and other fields to influxdb under additional data

• Quickest to do right now

[Zangetsu101]

We need to decide if we want to go forward with it as the quick fix would just be adding tech debt