Add more than one category and count for each event

[mraaroncruz]

This will surely cause some UX changes but the way I see it is:

• a link to add more categories in the add/edit form for a need
• the needs list isn't listed by need, but instead by categories, then needs (so the same need may be multiple times on the list)

The reason for this is that I don't even know if it's possible right now to create two needs at the same time. Even if you can, this is an unnecessary step for the user.

[klappradla]

The current data model can lead to a pretty cluttered calendar view for an NGO, that's right. However, I'd still estimate the classic use-case to be requesting a certain number of 'basic' volunteers for a certain timeslot and that's it. UI-wise, this should be easily and quickly archivable.

Maybe we need to change the data model to better resemble the calendar view as an NGOs main UI element. The key attributes of an entry would be time and place, the need(s) itself are actually just attached to an event. So I'd suggest the following data model:

Event	Need
start_time	event_id
end_time	vol_needed
description	category
location
city
user_id
(lng lat)

Event
has_many :needs, dependent: :destroy
accepts_nested_attributes_for :need

So we can easily provide the button @pferdefleisch mentioned + we can now actually use validations on the need model, since the calendar would only provide the wrapping Event object.

List view

We can show a list of needs (event by category), where an event might appear twice, but requesting different resources.

API

The API would need to include the associated event-object for a need, to still provide time and place.

What do u guys think?

[mraaroncruz]

👍

[mraaroncruz]

Though I don't agree with the nested part because the need gets added on edit anyway. This could be handled in the model (or maybe some kind of entity) from the controller.

[haslinger]

I think untrained ngo-admins could be overwhelmed.
Another way would be just aggregating in the view(s) and apps.

[klappradla]

How should we proceed here? Changes on the data model might impact other features as well.

In my opinion, wrapping needs within events is a semantically correct mapping of real world entities. @haslinger is of course right: it could easily overwhelm newcomers. So we should at least provide useful defaults.