Create role and panel for administering Tribal access via Django-Admin

[jadudm]

Background

We currently administer Tribal access for Federal users via the API. This means that only a few staff are comfortable adding/removing users and API keys (for system-to-system access).

As we are revamping the API, it became apparent that we would now need some of the API to point at the internal/production tables (for updating things like Tribal access), and most of the API pointing at the second/replica database (for public read of data). This means we have to add another PostgREST instance (one for the production/internal database, and one for the snapshot/read-replica). The goal of the API cleanup was to make things simpler, not more complex.

The proposal is to completely get rid of the management of Tribal access via API. This eliminates a great deal of code, and eliminates the concerns of "which API points where." To do this, though, we need to add the administration of 1) Tribal access users (email addresses) and 2) Tribal access API keys to the Django Admin panel.

We think this wants one more level of access in our panel as well. We currently have 1) read-only and 2) admin. We now want something in-between, where staff can be "helpdesk"-level, and can 1) read most things, but also 2) update the Tribal access stuff.

Although this introduces new code, it lets us eliminate a large amount of API code, eliminates the need for complex infrastructure changes, and moves the access control work into a space that is better understood by more of the team, and can be used/supported by more of the team.

Tasks

Tasks

Beta Give feedback

1. Create admin command/panel for adding/removing Tribal access users via email address
2. Create admin command for adding/removing Tribal API access via API key ID
3. Move suppoert_administrative_key_uuids to management as a Django model?

In a fancy world, we could add multiple email addresses in the first case. We can add API keys singly, as they will only ever come in batches of 1-3 (most likely). Email addresses sometimes show up as a list of 5-10 or more.

Note

I am going to, for now, preserve the creation of the table support_administrative_key_uuids. This may want to become a Django managed table.

[rnovak338]

The following changes are being made under the guidelines of this ticket and discussion with @jadudm this week.

Admin Panel

We are putting more emphasis on the Django admin dashboard in order to reduce complexity. The interface now provides two more tables: userpermisssions and tribalapiaccesskeyids, both with CRUD operations, in an effort to remove the "Admin API" as a blocker to helpdesk operations.

StaffUser Rework

We are now utilizing the Django out-of-the-box Groups table, which allows us to create roles and divide permissions across the team. With this, I am introducing two new groups: Read-only and Helpdesk.

• Read-only - with respect to the name, this role provides READ-ONLY access to the admin panel. This should be assigned to any team member that is not a part of the helpdesk.
• Helpdesk - this role provides everything from read-only, as well as permissions to use CRUD operations on the userpermissions and tribalapiaccesskeyid tables. Previously, this was only possible through the admin API, which blocked our helpdesk team from being able to move these tickets along.

As part of onboarding, new team members will be expected to include their name in a new JSON file which provides a list of users under these roles, as well as a superuser list. The only way they can be added to the admin panel is through approval of a PR which includes their name in this JSON, and the change getting deployed to production. There is a new script that triggers in run.sh which tears down and rebuilds the list of "staff users" based on this list.

---

All-in-all, this change eliminates the need for most of the Admin API functionality, which means less technical debt, and improved workflow for the helpdesk.