[Publisher] Agency Settings - Add new agency-wide Courts + Supervision Subpopulation TIG elements

[mxosman]

Description of the change

Add new agency-wide Courts + Supervision Subpopulation TIG elements in preparation for the implementation of this feature outlined in #1540.

Reference TIG:

• Courts: https://jc-tig.netlify.app/courts#criminal-courts
• Supervision: https://jc-tig.netlify.app/community_supervision#supervision-types

Also, I changed the folder name from Settings -> AgencySettings for more clarity (and b/c it was bugging me a lil' bit).

Type of change

All pull requests must have at least one of the following labels applied (otherwise the PR will fail):

Label	Description
Type: Bug	non-breaking change that fixes an issue
Type: Feature	non-breaking change that adds functionality
Type: Breaking Change	fix or feature that would cause existing functionality to not work as expected
Type: Non-breaking refactor	change addresses some tech debt item or prepares for a later change, but does not change functionality
Type: Configuration Change	adjusts configuration to achieve some end related to functionality, development, performance, or security
Type: Dependency Upgrade	upgrades a project dependency - these changes are not included in release notes

Related issues

Closes #1538

Checklists

Development

This box MUST be checked by the submitter prior to merging:

• Double- and triple-checked that there is no Personally Identifiable Information (PII) being mistakenly added in this pull request

These boxes should be checked by the submitter prior to merging:

• Tests have been written to cover the code changed/added as part of this pull request

Code review

These boxes should be checked by reviewers prior to merging:

• This pull request has a descriptive title and information useful to a reviewer
• This pull request has been moved out of a Draft state, has no "Work In Progress" label, and has assigned reviewers
• Potential security implications or infrastructural changes have been considered, if relevant

[morden35]

Looks good Mahmoud! Obviously this feature is still in progress, but is there any way to test the structure of this file? Also, is there any way we can add some sort of parity test between the two repos?

[mxosman]

Looks good Mahmoud! Obviously this feature is still in progress, but is there any way to test the structure of this file?

Ah, hmm... I could strongly type the constants in this file and that will enforce each one's structure is consistent - which is a great call - but, let me know if I'm misunderstanding what you mean by testing the structure of this file or if you were thinking of a test for the entire file itself? Here's the strongly typed version: 432806c

Also, is there any way we can add some sort of parity test between the two repos?

There isn't a way that I can think of off the top of my head without having some sort of linkage between the two repos - which I'm not entirely sure how we would do without publishing one as a yarn or npm package and importing it in the other repo. LMK if you have any ideas/suggestions!

[nichelle-hall]

Could you link to where I can find these definitions on the JC websites?

[nichelle-hall]

I can't find it on the link that is in the PR description.

[mxosman]

Oh strange - the link in the PR description takes me right to the supervision elements - I forgot to add the courts, which should be updated now.

Here is the a link to the file that Matt posted in Slack which includes both TIG elements along with the respective links to the JC websites that I used as reference: https://recidiviz.slack.com/archives/C04JL8A2ADB/p1727808639123169

Courts: https://jc-tig.netlify.app/courts#criminal-courts

Supervision subpopulations: https://jc-tig.netlify.app/community_supervision#supervision-types

[nichelle-hall]

Thank you!!

[morden35]

Ah, hmm... I could strongly type the constants in this file and that will enforce each one's structure is consistent - which is a great call - but, let me know if I'm misunderstanding what you mean by testing the structure of this file or if you were thinking of a test for the entire file itself? Here's the strongly typed version: 432806c

thank you for this! I think this looks good!

My original comment was referring to / asking how can we test that each given IncludesExcludes object is in the structure that the FE expects. However I'm not sure we can test this yet since it's not being used yet (if my understanding is correct)

[morden35]

[mxosman]

Ah, hmm... I could strongly type the constants in this file and that will enforce each one's structure is consistent - which is a great call - but, let me know if I'm misunderstanding what you mean by testing the structure of this file or if you were thinking of a test for the entire file itself? Here's the strongly typed version: 432806c

thank you for this! I think this looks good!

My original comment was referring to / asking how can we test that each given IncludesExcludes object is in the structure that the FE expects. However I'm not sure we can test this yet since it's not being used yet (if my understanding is correct)

Oh, gotcha!! In that case, I think the best way to enforce this/test it is by leveraging TypeScript and strongly typing it. That way, if you try to deviate from the structure you'll get hit with a TypeScript error immediately (directly in the IDE, via a pop-up in the browser when you run the app, and lint test failures). It would accomplish the same thing as if we wrote some quick smoke tests to make sure that each object has all the right fields and how I would go about checking & enforcing the structure.

Later on, useful tests for us to include would be - based on the agency's sector, does it show this field in the Agency Settings page - and, when they click the edit button, does it show all of the relevant TIG fields for that sector, and does it show all of the right defaults when they click on the JC definitions, etc.? (Sorry if I'm stating something that might be obvious to you!) But, you gave me another idea to make it even more safe and strict - especially if we want to add more TIG elements in the future - I'll consolidate everything into one object keyed by sector and strictly type that, which will help continue to enforce the structure when we make new additions and leave no room for deviations in structure without also explicitly updating the type.

[mxosman]

OK - this commit bf11169 should be more secure and will error if you don't adhere to the structure:

Removing an expected field:

Adding an unexpected field:

Adding an unexpected sector:

Using an unexpected value for default:

Using a non-string for the label:

[mxosman]

Also, is there any way we can add some sort of parity test between the two repos?

Oh, I thought about this a little more - I'm not sure how feasible this would be, but we might actually be able to write something on the recidiviz-data repo to fetch/access a file here given the file's URL and read it since this is a public repo (which probably means no permissions hurdles to cross). Even though it's no longer necessary, if we ever have a need in the future - it might be possible to do, but not sure how cumbersome it would be.