Skip to content
This repository has been archived by the owner on Jan 23, 2024. It is now read-only.

Adding Counties or Fields

Jump to bottom
Molly Trombley-McCann edited this page Nov 24, 2020 · 14 revisions

Managing Counties, Orgs, and Permissions (Fixtures vs Database)

Limited sets of the production data are committed to the repository and loaded into each environment upon release (including test, review, staging, and production). We also have tests that rely on some of these fixtures. Additionally, there are some things we can currently only do by modifying the fixture files, like adding a county or organization (see steps above).

For this reason, we should treat our committed fixtures as the source of truth and try to edit them (and then load them into production) instead of editing information in the admin interface. [Note: This does not include users—see below]

If we suspect that any of these have been edited in the Django admin, we should update them using the steps below as soon as possible.

Here are the essential fixtures loaded when manage.py load_essential_data is run:

Updating production database from fixtures

If we need to update one of the above models in the production database (County, Organization, or Group), update their corresponding JSON file above and add/edit/delete any related tests. Commit and push.

We run the load_essential_data as part of the Heroku release on all environments. This Django loaddata command. This means that any updates to existing models made in the database that are not reflected in the fixtures will be wiped out on next deploy. If we suspect that data has been modified in the Django interface, we should update the fixtures via steps below before the next deploy.

For more information about fixtures and their intended use, see the Django docs.

Updating fixtures from production database

Sometimes edits to database objects are made in the admin interface, which causes our committed fixtures (like user_accounts/fixtures/organizations.json) to become out-of-date. If we suspect this as happened, we should fetch and commit the latest fixtures to our local repository before the next deploy.

To do so, run:

export $(lpass show --notes "CMR Intake .env.prod" | xargs) && DJANGO_SETTINGS_MODULE=project.settings.prod make db.dump_fixtures && exit

This will close your shell session once complete, to prevent production environment variables from remaining set in your session.

If the script fails, be sure to exit the session, because the environment variables will remain set in the environment.

You will need to have access to the CMR-developers shared LastPass folder.

If you need to update the environment variables in the LastPass note, you can run heroku config -a intake-production > .env.prod, edit to make bash-compatible, and update note in LastPass.

Managing Users

Users and their preferences are managed entirely via the Django admin interface. See the related page in the wiki for more information.

Steps for adding a new county:

Before inviting users

  1. Add the county information to intake/fixtures/counties.json
  2. Add the organization's information to user_accounts/fixtures/organizations .json. If the is_live attribute is set to false, then the organization will not be an option on the /apply/ page nor will it be listed on the /partners/ page on intake-production (but it will be visible on intake-staging. This can be changed by setting the ONLY_SHOW_LIVE_COUNTIES variable to False). Be sure to also set 'is_accepting_applications' and 'is_checking_notifications' to false. These should be changed on "go live".
  3. List the org name and url in project/jinja2.py (Ideally this step will be refactored away eventually).
  4. Add a form specification for the county in formation/forms.py. Make sure to list it at the bottom in INPUT_FORM_SPECS.
  5. Write a method in intake/tests/mock_county_forms/__init__.py using the slug given in organizations.json.
  6. To load your new county and org, run ./manage.py load_essential_data
  7. Create new seed data and test fixtures for the county by running ./manage .py new_fixtures
  8. Add the newly created mock submissions fixture file (in intake/fixtures/) to MOCK_APPLICATION_FIXTURES in project/fixtures_index.py.
  9. Run the test suite, make test
  10. Manually verify that you can apply to the new county
  11. Manually verify that you can login as a user at the new county and that reviewing applications or opening PDF printouts shows all the information necessary.

Inviting county/org users

  1. Follow directions here. Only set "application_reviewers" as the permission group.

On go-live

  1. In user_accounts/fixtures/organizations.json, update is_receiving_agency, is_checking_notifications, and is_live to true. Commit, push, deploy.

Steps for adding a new field:

  1. add a class to formation/fields.py, and inherit from a field type that matches your needs. If you have a set of options, list them in intake/constants.py and import them.
  2. Be sure to set a display_label value, which is used to label the applicant's input when displayed for org users on the app detail page, in printouts, and in downloaded CSVs of applicant data. By default, display labels are generated from the context key by replacing underscores ("_") with spaces and capitalizing the first letter.
  3. List the field it in the correct location in formation/templates/intake_display.jinja template, using the _display suffix.
  4. List the field in printing/pdf_form_display.py so that it will be shown in printouts.
Clone this wiki locally