As a sys admin, I want a better django admin UX

[ADPennington]

For now, this is a stub for potential enhancements to consider only if decision is made to keep django admin. These enhancements will help make the following functions easier and/or more aligned with the principle(s) of least privilege:

• user account management
• monitoring report logs

This issue may need to be split up into separate tickets and/or this can be recycled into an epic. We may also want to consider these features for any TDP admin interface (even if we move away from django admin).

Weekly sys admin syncs w/ @ttran-hub help inform this list.

Potential enhancements:

• [ ] #822 (logging out from django admin)
• [ ] ability to deactivate multiple (test) user accounts at a time
• [ ] ability to confirm details about user accounts prior to deactivation (e.g. group, STT, last login)
• [x] ability to filter list of users by new request status, STT, region, group
• [ ] ability to filter log entries by filename, quarter, stt, etc.
• [ ] limit or eliminate the ability to add user accounts or add functionality to alert SO via email when system admin role assignments are applied to new user accounts.
• [ ] add another column to log entries to capture change message
• [ ] clarify the relationships between selections: active, staff status, superuser status, deactivated.
• [ ] view site takes us to a broken link. should it take us to the frontend?

[ADPennington]

curious about what drives this result in django admin when trying to delete an individual user: Deleting the user 'alex.soble@gsa.gov' would result in deleting related objects, but your account doesn't have permission to delete the following types of objects:

cc: @ttran-hub

[ADPennington]

curious about what drives this result in django admin when trying to delete an individual user: Deleting the user 'alex.soble@gsa.gov' would result in deleting related objects, but your account doesn't have permission to delete the following types of objects:

cc: @ttran-hub

learned during 6/2 dev-sync that log and report entries are associated with the user which prevents deletion.

[ADPennington]

this ticket will be updated once epic #1001 is refined and accepted into a sprint.

[ADPennington]

closing: moved relevant suggestions to roadmap mural on 7/13.

[amilash]

Im slating this fo rV3 and tagging as part of the DAC items that we may either extend in the Django (in V3?) or rebuild in the TDP app UI in V4.

[ADPennington]

2/10/2022 update: filtering user list by request status is being satisfied as part of #1495. updated summary above to reflect this cc: @ttran-hub

[ADPennington]

2/10/2022 update: filtering user list by request status is being satisfied as part of #1495. updated summary above to reflect this cc: @ttran-hub

actually #1495 is not satisfying the new request status filtering we are seeking. the access_request filter in that issue is distinguishing ever requested access status which will never change after an initial request is submitted.

It is unlikely that access request will ever be no in prod since no one should have an account unless they've requested one. So for future, we need to distinguish new requests i.e. :

• access request = yes
• role = null
• superuser status = null
• staff status = null
• deactivated status = null

cc: @ttran-hub

[ADPennington]

revisit after #1605 refined.

[stevenino]

This is beyond the scope of parity. It will be moved to V4 per backlog refinement on Jul 6.