Case insensitive admin search, testing updates and manager setting of notes and report status

[jasalisbury]

Allow search to be case-insensitive

Description of change
User search is now case-insensitive in the admin page

How to test

1. Pull down changes
2. Go to admin page
3. Type a users name in a mixture of upper/lower and you should still get the desired user (if exists)

Issue(s)

• closes Allow searching of users be case-insensitive #274

Create separate docker-compose file for running tests, add bin/run-tests command for easy testing

Description of change

While looking at issues with the backend tests, I saw some room for improvement with how docker tests run locally. The bin/run-tests file is the culmination of my attempts to sandbox docker-tests from docker-dev environment.

I tried multiple docker-compose.yml files, but that had many issues. For one, overrides don't override multivalve options. Another issues was Docker not treating the different configurations as different services, so it wasn't using the test-db when expected.

I looked at the circleci CLI, but that only runs jobs, not workflows, and the circleci needed to run tests is two jobs. There may be something useful here, but also introduces another tool.

If you look in the commit history, you can also see that I wrote a much longer bash script initially, in part to help me experiment with multiple docker-compose.yml files and in part to compose a number of smallish docker commands into larger actions. When I realized multiple docker-compose.yml files wasn't going to work, this tool became unnecessary. You could retrieve it via git checkout 8b0beced865b3a9733bb5c61123dcc9d33451981^ -- bin/docker-run if you're interested.

How to test

Run ./bin/run-tests then start your regular Docker environment. Running tests should not overwrite/modify your development database.

Issue(s)

• closes Backend tests too brittle. #263

Managers can add notes and set status of reports

Description of change

• Review page is now different if the user looking at the page is the approving manager
• Manager's review page includes the user's additional note and allows the manager to leave a manager note
• Manager note added to DB
• Report state is shown in the side nav's "review" section once it leaves "draft" mode
• Policy, service and route added to update status of a report

How to test

1. Pull down, run migrations/seeders
2. Make sure the CURRENT_USER_ID is set to "1"
3. Fill out a complete report. Add "Hermione" as the approving manager
4. Refresh the report, since Hermione is user with the id 1 you should see the approving manager version of the review page.
5. Add a manager note and set the status. Note once you submit the status on the side nav Review and submit section updates
6. Refresh the page to verify the manager notes persists

Issue(s)

• closes Manager Note for Activity Report #138
• closes Approving manager adding note to activity report #231
• closes Manager update of AR status #236
• closes Manager approves an Activity Report #137

Checklist

• Meets issue criteria
• Code tested
• Meets accessibility standards (WCAG 2.1 Levels A, AA)
• Documentation updated
  • API methods
  • Boundary and Data Flow Diagrams
  • Architectural Decision Records written for major infrastructure decisions with the Nygard template
  • OSCAL templates completed when security controls are implemented or modified

[rahearn]

Code looks good, but in my testing there are a couple of issues with the activity report that I'd like to see cleaned up.

1. When the approving manager is a different user than the report creator, the auto-save fails (good! they shouldn't be able to save the report details) and shows a failure message. Please disable autosave when the approving manager is reviewing.

2. I don't think this is related to these changes, but I'm often getting a failure where the save status is not displayed. Looks like it is related to this console error:

[rahearn]

This doesn't work. Looks like a missing container_name for the frontend service. --cwd frontend is also unnecessary (though doesn't break anything) in the frontend container.

That also exposes that this script papers over any failures if you don't read the output carefully. Since this is not used in CI/CD I think I'm ok with that, but I think it'd be good to collect exit statuses and exit the script with non-zero if any individual step exits with non-zero, or just bail out as soon as we get a non-zero.

[dcloud]

Hmmm, I've run this a few times and haven't seen this problem. I'll take a look again. Could you get me the output of docker-compose -f docker-compose.test.yml ps --all on your machine?

As for handing failures, it was intentional that we didn't error out if one of the intermediate steps threw an error. We could catch those statuses, but I'm not sure we want to prevent frontend tests from running if the backend tests fail, for example.

[rahearn]

I'm not sure we want to prevent frontend tests from running if the backend tests fail, for example

Yeah, I went back and forth on that. I'm 100% fine with all the steps running as long as I get a nice clear indication that at least one step failed when the script exits.

Here's the ps output:

[dcloud]

Just a quick check of the doc page for docker-compose exec, it sounds like that command takes a service name rather than a container name, so that might be related.

While we're discussing, I had originally considered having the frontend and backend tests run as separate scripts, since it seems like engineers might be focused on either frontend or backend during development. Would you be interested in making this accept an optional frontend/backend param?

[rahearn]

Would you be interested in making this accept an optional frontend/backend param

If it's quick, sure, but that's pretty low priority to me.

[dcloud]

It was quick: https://github.com/adhocteam/Head-Start-TTADP/pull/149/files

I also added some logging of errors and have the script return an exit code value equal to the number of script failures.

[rahearn]

🎉