Organizer should be able to configure food options

[lilliealbert]

Should allow:

• Disabling food preferences altogether (we shouldn't say "the food's on us" if food is not provided.)
• Disabling specific food preferences (allow just a 'vegetarian' checkbox but not 'gluten free')

[JasonEb]

Hi @lilliealbert, I'm thinking of taking this issue on, and I'm curious to what kind of approaches you've considered for this!

I think it boils down for the _form partials for rsvp's and new events having access to a @event.food_provided? kind of method so they can decide if food options are available. Upon an organizer creating an event, It would like something like this

However, my main approach to enable this would be to introduce a boolean column for a food_provided column in the Events table for the database.

This would require a migration to add the column, but I believe then we'd have to update all the previous records so there won't be any nil values.

I'm still digesting the codebase, but if #food_provided doesn't rely on a new attribute, would it consider some sort of logic with the dietary_restrictions?

Pursuing the back-end migration approach, I'd introduce more specs to the event model and feature specs for event creation and rsvp response. However, I'm not sure if this approach works well yet with the second part of this issue, where one can filter food options if enabled, and if it'll play well with the EventEditor abstraction when updating the events.

So in summary, would it be appropriate to introduce a migration to add a food_provided boolean attribute to Events, so we can toggle food options? Thanks for any insight!

[tjgrathwell]

The new food_provided column sounds good. The migration that adds it should probably set it to true for all existing events.

[JasonEb]

Hi, just wanted to update with my approach and talk about part ii of the issue. As it stands, I can submit a pull request to disable food options from the Organizer tools, so they won't show up in rsvps. Here's with it enabled:

Then when the event doesn't have it enabled in Organizer Tools:

This works for both Student and Volunteer RSVP forms, where I believe the issue takes place. I've introduced specs here and there targeting creating events and RSVP forms, and I have this update ready for review at my forked repo here https://github.com/Holyoke/bridge_troll/tree/issue-325-disable-event-food-options. All specs were good to go as well.

I'd like to talk about the second part of this issue - disabling food preferences. To my understanding and interpretation of the dietary restrictions and the user workflow, I don't think Bridge Troll needs to implement select or filtered food options. They're ultimately restrictions - Bridge Troll is not asking users what they want for food, but rather, what food they can't have...if food is provided.

Ideally, I believe the issue would like to have not all food options have checkboxes, and I think the implementation would be rather significant. It seems with the way event, rsvp, and dietary_restrictions are setup, it was designed for restrictions to only be read by events. One approach I'd consider is making a new dietary_options column to event's so the dietary restrictions can read from that instead of a DIETS constants. This would be the main code to tackle in my opinion, since the _dietary_restrictions.html partial relies on this too:

Another option is to add a direct association between events and dietary restrictions, but that would still involves a migration and logic.

To sum things up, I think the disabling food preferences feature is powerful enough for Organizers. I don't think the need for disabling specific food preferences is necessary - if food is provided, then organizers will receive dietary restrictions normally and can plan around that.

Please let me know if there's any issues or code clean-up, and if you have any insight on how to approach the second part of this issue. I can follow-up at Google Groups as well if that is preferred!

[lilliealbert]

@Holyoke Please do submit a PR for the turning-off / turning-on functionality! That will be a good configuration to offer.

The reason that food needs should be configurable is that paying for all the combinations of vegan/veggie/gluten-free/dairy-free can be very expensive, and that not all workshops will be able to find catering in their area that will cover those needs. I want Bridge Troll to be able to support organizers in lots of different cities, with more limited budgets, and not have very disappointed people whose food restrictions are offered but not actually provided for at the event. (For example, getting a gluten-free pizza is not a trivial task, and if you want to offer meat & vegetarian options, but can't spring for gluten-free pizza, what should you do?)

It's totally okay if you're not pumped for implementing the food preferences feature, but I do think that it's needed.

[JasonEb]

@lilliealbert More than happy to to tackle more food options! I thought there was a discrepancy between the issue and implementation, since the relevant model was cited as dietary restrictions. I do believe in the value of the food options, but I also was unsure on how to implement it as well. Nonetheless I wanted to present the food options toggling first, before working on the second part of the issue.

I'll clean up the branch and push the PR for food options toggling. I'll revisit configuring options - the main approach I'm considering is introducing a new migration for FoodOptions to integrate with Events, but I'm also trying to determine a way to implement food options without another migration, and instead exploring the relationships between the event and dietary restrictions. Any insight on this feature implementation would be greatly appreciated!

[lilliealbert]

@Holyoke Cool — I think emailing the mailing list is a good idea for getting architectural advice. (I'm a bit spread thin at the moment, so more hands on deck would be great.)