10455 Story: Add/Remove/Modify Judge Users

[Mwindo]

Purpose

We hard code chambers data in getJudgesChambers.ts and in add-user.ts. This requires us to deploy code in order to add/remove/update a judge. The goal of this PR is to decouple modifications to judges and code deployments in test/prod and to provide clear steps for onboarding/updating a judge. (#5217 demonstrated to us that this process was not clear/well-documented.)

Note that this PR attempts to do the minimal-ish work possible to accomplish these goals.

Current Problems

1. Hard-coded data

Functionally, we use hard-coded chambers data in a few spots:

getJudgesChambers.ts

• When calculating the trial session form in computeTrialSessionFormDataAction.ts.
• When getting the information to display the available chambers sections in the message modal dropdown here.
• In tests. E.g., here in mockUsers.ts.

add-user.ts

• When validating the addition of a new, non-judge user.

This PR removes the above hard-coded logic and instead creates a new endpoint (and associated lambda, proxy, and actions) to get/set judge chambers information from our database. It also makes slight updates for loading judges in non-test/prod environments. (See Environment-Specific Considerations below.)

2. Unclear processes for adding/updating a judge

Our processes for onboarding/updating a judge are not well-documented and are ad-hoc. (See this PR.) This PR adds a few (admittedly miserable) scripts as a slight improvement.

Broad Overview of the Implementation

Most of the hard-coded data we want to decouple from is already available in the database. The one exception is judge chambers' phone numbers; they were only ever in getJudgesChambers.ts. Maybe the most conceptually appropriate way to get them into non-hard-coded persistence would be to add the phone number to the chambers record (and maybe even create a chambers entity) since, technically, the phone number is for each judge's chambers section and not for the judge themselves.

However, our chambers records are currently very sparse; in fact, the only attributes they have are the pk (e.g., section|soAndSoChambers) and the sk (which is just the userId of the judge). Given the added complexity of the "chambers-first" approach (which would require stitching together some records)--and given the fact that the only non-pk attribute for chambers' records is just a reference to the relevant judge anyway--I decided on a "judges-first" approach in which we add the phone number to the judge record. This is easier because 1) we can get all the information we need from one set of records rather than stitching data together and 2) a judge is already a User entity with a contact attribute.

Environment-Specific Considerations

We have to update judge phone numbers in three separate ways depending on the environment:

• For local data, we need to add the phone number (when applicable, i.e., when it exists in getJudgesChambers.ts) to the judge users in efcms-local.json. (Otherwise, tests relying on this, if any, will fail.)
• For data in deployed environments other than test/prod, we need to update judge_users.csv and bulkImportJudgeUsers.helpers.ts similarly.
• For data in test/prod, we need to "manually" add the information. I've provided a one-off script, add-phone-numbers-to-judge-records.ts, to update current judges. I've also provided add-judge.ts and update-judge.ts so that new judges can be onboarded/updated more efficiently.

Manual Steps

We need to run scripts/run-once-scripts/add-phone-numbers-to-judge-records.ts before deploying.

Fast-follow tasks:

After scripts/run-once-scripts/add-phone-numbers-to-judge-records.ts is run, we should pare down and maybe remove entirely JUDGES_CHAMBERS. While still used in some tests, I believe we may only strictly need it for the one-time script add-phone-numbers-to-judge-records.ts.

We can also remove scripts/run-once-scripts/add-phone-numbers-to-judge-records.ts.

Issues:

• Fix legacy judges appearing in exp1
• Fix User contact validation errors (and/or tests)

Tests:

• Test scripts/run-once-scripts/add-phone-numbers-to-judge-records.ts in experimental
• Test scripts/user/add-judge.ts in experimental
• Test scripts/user/update-judge.ts in experimental
• Make sure scripts/user/add-user.ts get the chambers sections dynamically in experimental
• Make sure that messages dropdown works for chambers selection in experimental
• Make sure that phone numbers appear in the trial session information in experimental
• Test scripts/run-once-scripts/add-phone-numbers-to-judge-records.ts in test
• Test scripts/user/add-judge.ts in test
• Test scripts/user/update-judge.ts in test
• Make sure scripts/user/add-user.ts get the chambers sections dynamically in test
• Make sure that messages dropdown works for chambers selection in test
• Make sure that phone numbers appear in trial session information in test
• What, exactly, do we need the test Judges chambers for now? Can we at least remove those phone numbers? A: We need this 1) to add the phone numbers to Dynamo in add-phone-numbers... and 2) something like this, at least, for test data like in messageModalHelper.test.ts.
• Update offboard-judge-user.ts
• Update documentation for onboarding/updating/offboarding
• Test that judge_users.csv is loaded correctly on experimental environment
• Test above scripts and add-user.ts (updated to get chambers dynamically) on experimental
• Add the manual deploy steps needed for this PR. (And clarify what they are/what order. E.g., we might need to modify the validation code first to avoid judge users being "invalid" if they have contact: phone.)
• Check validation works. Clean up console logs, poor typing, etc.
• Make sure there is no getCurrentUser (merge in 10417)

Fast-follow tasks:

• Pare down and maybe remove entirely JUDGES_CHAMBERS. While still used in some tests, I believe we may only strictly need it for the one-time script add-phone-numbers-to-judge-records.ts.

[Mwindo]

To be pared down or removed after we run scripts/run-once-scripts/add-phone-numbers-to-judge-records.ts

[Mwindo]

Judge 1 is above

[Mwindo]

Updates to chambers are relatively infrequent, so I think it is best to cache.