single entries for food preferences

[Nebucatnetzer]

#62 #76
at the moment food preferences are just a text field which makes it a bit hard to format.
It would probably make sense to collect this as single items.

[bendauphinee]

Or even tags might make sense here, instead of even single items. That way, if you were planning a party, you could set a guest list and pull the common tags for the people coming (hypothetical scenario / feature).

[jcassee]

I'm looking at an interesting first issue to try and fix. Is the idea to have the Food section work like the Pets or Contact info sections (but probably without a type field)?

[bendauphinee]

That seems like a reasonable idea!

[jcassee]

Alright, my idea: food preferences is a separate table, á la pets. A preference is combination of a type (with icon) and a text line. Preference type are:

• 👍 like
• 👎 dislike
• 🚫 allergic

This list can be extended and the preference type can be null.

The change would consist of:

• Database migration:
  • New database tables food_preferences and food_preference_types.
  • Insert food preference types.
  • Split current contact field food_preferences by newline and insert as food_preference records without type.
  • Remove food_preference field from contact.
• Change food preferences frontend component to work just like pets.

Suggestions for better naming and other ideas very welcome.

If this sounds good I'll create a PR.

[vgaldikas]

Split current contact field food_preferences by newline and insert as food_preference records without type.

Are we sure that everyone splits the preferences by new line, and not by comma for example? Maybe better solution would be to at least temporarily maintain the legacy field as 'read only', giving users opportunity to migrate to new format by themselves manually, if they chose so.