I'd like to pick this issue up.

Go for it!

It looks like we're currently storing the agency type description string in the database (not the code). Do we want, as part of this PR, a migration to convert agency types from, for example, Government Agency/Affiliate to GOVT?

Hmm... that's a good question. I think it's definitely a better approach than storing the full string. We'd have to be very careful about the rollout, though.

I think we'd have to do something like allowing both long and short values in the enum hash, then doing the migration, then removing the long values from the hash.

This issue is marked as stale due to no activity within 30 days. If no further activity is detected within 7 days, it will be unassigned.

We're just waiting on a data cleanup (#4261) before we move forward on this one.

Automatically unassigned after 7 days of inactivity.

NDBN sent me back some stuff, but I need to review it -- probably a Monday job at this point.

I had provided the requested mapping on #4261 but it hasn't been finished. That would be the next step on this.

May I work on this one?

Please do.

Looking at the migration made in #4801, it seems like things are already set up to store the agency type codes (GOVT, CAREER, OTHER, etc.) in the db. Do we also want to have a map from these enumerated codes to the existing full description strings?

As input into that, I can say that we show the full description strings to the users for selection -- I'm not sure off the top of my head of we ever show the agency type codes to the users -- maybe in the export?

I'll do some digging to get a better sense of how we're currently using the agency type codes and full description strings.

Alright, here's what I found. As far as I can tell, it seems like the type codes aren't used, but it's muddy.

There are a number of places that use the agency_type attribute directly from the database. The various views for CRUD operations on a partner's profile, the PartnerInfoReportService which populates the annual survey report, and the attributes for exporting a partner to a CSV.

The Partner::AGENCY_TYPES mapping is only used in the Partner class itself to compare the full strings to the agency_type attribute, and in the forms to get a list of the available full string options. It isn't ever used to convert a code from the db to a full string.

If we assume the code expects the db to contain the full descriptive names, then all this would be consistent with your recollection that we use the full names in the partner edit form and point to type codes not really being used. However, this would be inconsistent with the migration made in #4801 which seemed to want to move the values in the db from full strings to the type codes.

The db currently has the full string, but we want to move away from that. #4801 was a cleanup necessary to make that possible. It's a bit of a weird situation because the field used to be free-form.

@dorner - can you chime in on this?

Yeah - let's create a mapping in code for this (so e.g. "GOVT" => "Government Agency/Affiliate"). Maybe a nice way to do this would be to use i18n for this (in en.yml). I definitely don't want the full strings in the database.

I've found two ways to handle translating the agency_type values into the full descriptive strings within views.

Option one is to rely on Rail's lazy lookup which will look up translation keys based on the file path to the file in which the translation is occurring. In this case, the translation file looks like this

en:
  profiles:
    show:
      *agency_type_map

  partners:
    profiles:
      show:
        agency_information:
          *agency_type_map

And in the views the translation is queried like this

Agency Type: <%= t ".#{partner_profile.agency_type}" %>

Option two is to specify a specific key(s) for the translation in the view, which lets us organize the keys in the translation files however we want. In this case, the translation file looks like this

en:
  partners_profile:
    *agency_type_map

And the views themselves look like

Agency Type: <%= t partner_profile.agency_type, scope: [:partners_profile] %>

Do people have preferences between these two methods? From my perspective, I am leaning towards option two because it avoids:

• Repeating translations for each view in which agency_type is used
• Having to refactor the translation keys if the views' name or file structure is refactored

I would lean that way, too, but it's @dorner's call.

Option 2 is definitely a lot cleaner.