(on getgov-litterbox) Ticket #2301: Fill federal agency type

zandercymatics commented 1 week ago

Ticket

Resolves #2301

Changes

Adds a script that fills federal agency type from the DomainInformation model => FederalAgency model
Adds documentation for our terminal helpers in general (since it was missing and this would be good to have anyway)
Expands the PopulateScriptTemplate class to be more broadly useful

Context for reviewers

This ticket, more broadly, adds a script that will fill the federal_typefield on FederalAgency.federal_type. This federal_type value is obtained from our DomainInformation records.

To see the run result of this script on our data, visit getgov-litterbox

Broadly, what does the script do? This script does 3 things:

Grabs all DomainInformation objects
Grabs all FederalAgencies that have a value on the name field for the record: "FederalAgency.agency" (otherwise - there's no point!)
On each FederalAgency record, grab the related DomainInformation object based off of the agency name. If the data doesn't look wonky, then we apply the value!
Log what happened along the way and at the end.

There are two tickets to run this script: https://github.com/cisagov/manage.get.gov/issues/2383 https://github.com/cisagov/manage.get.gov/issues/2382

See this slack thread for more information

Setup

Testing locally or on a sandbox a) on a sandbox: /manage.py transfer_federal_agency_type b) docker-compose exec app ./manage.py transfer_federal_agency_type

Do note that this script assumes that DomainInformation is generally accurate, so if there is incorrect data there for federal agency (fixtures data) then that will percolate. There is one check in place that sees if there is a disparity between multiple records (which tells us the data is wrong), and that is generally effective at weeding that out - but not entirely for fixtures only data.

Verifying that the script works with prod data a) Visit the getgov-litterbox sandbox OR b) Run the import script on a sandbox of your choice as documented in our readmes and run the script

Code Review Verification Steps

As the original developer, I have

Satisfied acceptance criteria and met development standards

[ ] Met the acceptance criteria, or will meet them in a subsequent PR
[ ] Created/modified automated tests
[ ] Added at least 2 developers as PR reviewers (only 1 will need to approve)
[ ] Messaged on Slack or in standup to notify the team that a PR is ready for review
[ ] Changes to “how we do things” are documented in READMEs and or onboarding guide
[ ] If any model was updated to modify/add/delete columns, makemigrations was ran and the associated migrations file has been commited.

Ensured code standards are met (Original Developer)

[ ] All new functions and methods are commented using plain language
[ ] Did dependency updates in Pipfile also get changed in requirements.txt?
[ ] Interactions with external systems are wrapped in try/except
[ ] Error handling exists for unusual or missing values

Validated user-facing changes (if applicable)

[ ] New pages have been added to .pa11yci file so that they will be tested with our automated accessibility testing
[ ] Checked keyboard navigability
[ ] Tested general usability, landmarks, page header structure, and links with a screen reader (such as Voiceover or ANDI)
[ ] Add at least 1 designer as PR reviewer

As a code reviewer, I have

Reviewed, tested, and left feedback about the changes

[ ] Pulled this branch locally and tested it
[ ] Reviewed this code and left comments
[ ] Checked that all code is adequately covered by tests
[ ] Made it clear which comments need to be addressed before this work is merged
[ ] If any model was updated to modify/add/delete columns, makemigrations was ran and the associated migrations file has been commited.

Ensured code standards are met (Code reviewer)

[ ] All new functions and methods are commented using plain language
[ ] Interactions with external systems are wrapped in try/except
[ ] Error handling exists for unusual or missing values
[ ] (Rarely needed) Did dependency updates in Pipfile also get changed in requirements.txt?

Validated user-facing changes as a developer

[ ] New pages have been added to .pa11yci file so that they will be tested with our automated accessibility testing
[ ] Checked keyboard navigability
[ ] Meets all designs and user flows provided by design/product
[ ] Tested general usability, landmarks, page header structure, and links with a screen reader (such as Voiceover or ANDI)
[ ] Tested with multiple browsers, the suggestion is to use ones that the developer didn't (check off which ones were used)
- [ ] Chrome
- [ ] Microsoft Edge
- [ ] FireFox
- [ ] Safari
[ ] (Rarely needed) Tested as both an analyst and applicant user

Note: Multiple code reviewers can share the checklists above, a second reviewers should not make a duplicate checklist

As a designer reviewer, I have

Verified that the changes match the design intention

[ ] Checked that the design translated visually
[ ] Checked behavior
[ ] Checked different states (empty, one, some, error)
[ ] Checked for landmarks, page heading structure, and links
[ ] Tried to break the intended flow

Validated user-facing changes as a designer

[ ] Checked keyboard navigability
[ ] Tested general usability, landmarks, page header structure, and links with a screen reader (such as Voiceover or ANDI)
[ ] Tested with multiple browsers (check off which ones were used)
- [ ] Chrome
- [ ] Microsoft Edge
- [ ] FireFox
- [ ] Safari
[ ] (Rarely needed) Tested as both an analyst and applicant user

Screenshots

zandercymatics commented 1 week ago

This ticket will be split into two. One with the documentation additions + the template, the other with just the script.

I also am debating on including those additions or not to begin with. The last 5+ scripts have generally followed the exact same pattern, so I'm thinking this could be helpful.