Add product and production type to claimed facility profile

[jwalgran]

Overview

Brief description of what this PR does, and why it is needed.

Connects #652

Demo

Optional. Screenshots, curl examples, etc.

Notes

Optional. Ancillary topics, caveats, alternative strategies that didn't work out, anything else.

Testing Instructions

• How to test this PR
• Prefer bulleted description
• Start after checking out this branch
• Include any setup required, such as bundling scripts, restarting services, etc.
• Include test case, and expected output

Checklist

• fixup! commits have been squashed
• CI passes after rebase
• CHANGELOG.md updated with summary of features or fixes, following Keep a Changelog guidelines

[kellyi]

We do not currently have a select box with these settings here but I left open the possibility that we could.

[kellyi]

I revised how these serializers were working to make them return a list of tuples like [("Accessories", "Accessories")] etc. This matches how the other choice serializers work here which makes it easier to reuse the existing mapDjangoChoiceTuples stuff in the client.

[jwalgran]

👍

[kellyi]

I tested this out including my fixup and it is working well! I'm going to make a note of a place where I'd like a check on my reasoning in the serializer.

[kellyi]

I'd like to check my reasoning here a little bit:

• the values_list call for seeds will always return a list because of our data migration
• the values_list call for facility_product_types will return None if no custom types have been entered
• the values_list call for facility_product_types returns a list of lists when it does return values

So we check whether new_values.exists() here to see whether it is not None and if it is not, we remove one level of nesting by getting the 0th index. If it is None, that's okay because the or [] thing in the list comprehension above will just make values into an empty list.

Subsequently we union the seeds and custom values together, then sort them alphabetically before making the tuples to send back as choices.

(Same logic for production types, btw). Does this seem reasonable? I tested it out and it worked both when there were no existing facility_product_type values and when there were some existing values.

[jwalgran]

I tested this reasoning by adding products to 2 different profiles. It does not look like we want new_values[0]

>>> new_values = FacilityClaim.objects.all().values_list('facility_product_types', flat=True)
>>> new_values
<QuerySet [['Bedskirts', 'Foo'], ['Chaps', 'Foo', 'Spats']]>
>>> new_values[0]
['Bedskirts', 'Foo']

We can combine set and itertools.chain to get a set that we can union with our seeds.

>>> from itertools import chain
>>> set(chain.from_iterable(new_values))
{'Bedskirts', 'Foo', 'Spats', 'Chaps'}

Going to rework this if you agree.

[kellyi]

Sounds fine to me -- the main thing I was interested in doing is to make sure we return the list of choices formatted like [('A', 'A')] from the API since that's generally what the client expects for these. Feel free to adjust how we get there, though.

[jwalgran]

Will do

[kellyi]

Just noticed that I made a naming mistake here by leaving Prime on the end of this, from when I was trying out a couple ways to generate these partitions. I guess it doesn't hurt anything to leave it but if we'd like we can adjust the name to be just newlyCreatedOptions.

[kellyi]

Just noticed that these need to be arrayOf(arrayOf(string)) now.

[jwalgran]

Thanks for helping me finish this up. Sorry your contribution was lost to rebase.