Using the api I talked about in issue #521. With the csv file, we could enumerate through the whole thing with only a little mapping required between things like Instance Types being referred to as instance_instance_types for the Enumeration code. The value code is the exact item that ConfigurationChoice value would use, and the display_name can be supplied by using Value. The Value is what ASpace has recorded for the Translation section for that item in the Controlled Value List. That means some custom user items will have the same text if the user has never edited the translation file to include it. Which is why I consider the approach of getting the data from the csv to populate and keep the database up to date with new items, while the database admin can further refine the display_name for the values if they want them to be different.

Some caveats or potential problems I can see. The populating of the database should not update existing info to not remove user edited data. You need a new mapping to map the types that your code expects like the INSTANCE_TYPE_CHOICES, LEVEL_CHOICES, etc. I noticed that you had left these mappings in the config.py. I'm not sure why. I also noticed in this specific case that the csv contains multiple note types that I assume should be condensed into a single NOTE_TYPES that you have. Which would require to map each type of notes to only note_type before adding them to the database. The last issue is I'm unsure since this is two years old, what else changes to the code that may have affected it.

Hi @Tyl13 thanks for thinking this through and suggesting this approach. The reason we are checking these in the first place is that it's actually easier than you'd think (and honestly easier than it should be) to add erroneous values to enumeration lists in AS. Any time you import something via EAD (and possibly CSV but I'm less familiar with that) AS will silently add any enumeration values it needs to successfully import that thing. So, for example, if you import something with a typo in an instance type, you now have that incorrect instance value in your AS instance. While I think this could work as a way to load initial data, I'm not sure that the work required makes it that much of a better option than using a Django migration.

The NOTE_TRANSFORM_TYPES list is used to determine which notes to transform. It's used primarily to filter out note types that we don't want to include in the transformed data. I am also not sure why I didn't include those, but probably just an oversight!