Custom activity and place types

This has been a long discussed topics in various forms! :

The concrete things that have been done so far are:

  • implementation of “general” and “bikekitchen” themes that make karrot more suitable for other non-foodsaving purposes (limited to frontend changes in language and images - and English only)
  • rename stores to places and pickups to activities everywhere in the code and database (but “pickups” is still the word used everywhere)

I’m ready for the next step now - custom place/activity types :slight_smile:

Sorry it’s a big wall of text, and no nice explanatory pictures or user interface mockups… (would welcome collaboration for anyone who wants to do some of that too!).

When we renamed stores to places there was some resistance as not all groups need this stuff, and perhaps are concerned it will stop working so well for foodsaving groups, or confuse the users.

So I think it’s important to be clear that foodsaving groups are a really important use for karrot and will always be important, any of these changes should be so that:

  • foodsaving groups can organise the themselves better (as not all their tasks are “pickups” at “stores”)
  • non-foodsaving groups can use karrot too without being confused why there are these “pickup” things, and lots of food-related stuff
  • groups can actually be mixed-purpose, and configure their group to work in the way they want

There have been many discussions and it’s been quite unclear how to progress with this, but I have some clarity now and so this is a proposal for how to progress it…

  • each group would have their own activity and place types, existing foodsaving groups would automatically get a “pickup” type (and perhaps a “store”) type defined for them
  • new groups registering would be setup with a default set of types (at some point they could pick a “group template”, e.g. “foodsaving group”, which would set them up with a predefined set of types)
  • at any point groups can add/remove/modify their activity/place types

Initially I’m thinking that the types would have the following things:

  • a name (e.g. “pickups”, “meetings”, “stores”, “drop off points”)
  • a colour (to show in interface and for place map markers)
  • an icon (to show in interface and for place map markers)
  • for activities:
    • whether to collect feedback
    • whether to collect weight for the feedback

And later on some other ideas:

  • custom fields
  • custom fields for the feedback
  • enable/disable some of the standard fields (e.g. whether a location is required)
  • custom translations for the type name (so if a group has a special word for a “pickup” they can use that, but also translate it into other languages if their group is multi-lingual)
  • some control over the notifications that are relevant for that type
  • custom place status options (i.e. don’t have to have “co-operating” as the active status)
  • whether an activity needs to have slots at all (maybe some are just more like public events)
  • whether an activity needs a place (see Decouple pickup/event and store/place #1128 )

What does this solve?

It’s quite important to make sure whatever we are making, it’s going to solve something real! So I’m thinking that after doing this, the following things should get much easier:

  • organising meetings
  • adding sharing locations (fair share points, public fridges, etc)
  • using places as “virtual” spaces for organising (e.g. for discussions)
  • co-ordinating a bunch of more specific tasks for things like foodsharing brunches, or festivals (see Generalization of store pickups for other tasks #359 ) - here maybe a “foodsharing brunch” type for the actual brunch event, then a more generic “task” type for related activities (opening up, cleaning, etc…)
  • … more things?

Implementation details

I’ll just mention a few details here, but not go into great depth:

  • new db models ActivityType and PlaceType with required typus fields on activities/series/places
  • initial fields for ActivityType:
    • name
    • colour
    • icon
    • feedback (boolean)
    • feedback_has_weight (boolean)
  • db migration to create “pickup”, and “activity” (generic) type, and set existing activities to be pickups or activities depending on theme
  • for custom fields I am thinking extra db model for each field definition, e.g. ActivityField, which holds info that is used to dynamically create a DRF Serializer, that is used to manage data in a JSONField on the activity/series/place. This could then be just simple types (e.g. textfield), but also more complex types (e.g. a choice field with options), or even complex nested types (e.g. an “opening times” field?)… (I can imagine people then want types like “user”, or “place” or “image” fields, which get even more complex, or messy :confused: )
  • possibly useful to populate colour/icon fields on the activity/series/place itself too, and allow them to have an override setting for an individual activity/series/place…

I’ll stop now as this has got a bit long… would be very interested in thoughts feedback. Ping @tiltec, @djahnie, @bruno, @karolina, @danveg, @Disa, @mzpawlowski, @Teddy, @ConexionUtopia - everyone else welcome to feedback too :slight_smile:


Here’s my contribution… A mockup of how it could look like on the sidenav menu and on the activities page, just to get the visual imagination going. We could also do other mockups, like the page to select and create types of activities and places.

1 Like

Thanks for creating this detailed proposal, @nicksellen, and for the mockup, @bruno! Thinking of food saving groups, I imagine that this will make it easier to include sharing locations and event planning.


Damn, I even forgot the sharing locations on my mockup! :slight_smile: At least in my group we would definitely have them.