Events always have a Partner (who organises it) and can optionally have a Place (where it is) and/or Address. This is why the database structure works how it does now.
This document is therefore about how to deduce Place, or not.
Events should show up in three places:
The first step in starting a new PlaceCal instance is often based on an existing neighbourhood calendar someone has set up by sharing a Google calendar, or with an area Facebook group or the like. In the first instance we want to just import this calendar to give immediate value.
This big source calendar might have events on by say, 6-12 partners, with a mix of regular and one-off events. The location field in the calendar is how we tell them apart, but it’s fair to assume addresses will be input inconsistently.
The idea is that as time goes on, they onboard the partners on the calendar directly and delete them from their source calendar.
This is what the event strategy is designed for.
We could potentially add a field to the Calendar model to indicate if the person listing the events is the organiser or just some helpful community development officer who happens to be uploading them.
In the first instance when we had only one area this was a non-issue - it just imported everything anyway.
At some point we made the ‘organiser’ field mandatory, which fixed a lot of these issues but it still makes this case tricky for this scenario. Maybe we need an option to have “organiser” be more like “event listed by” so that they show up on the person doing the listing’s partner page but it’s clear they’re not by that partner.
Response: Place: nil, Address: nil, flag warning for each event
It should look at the address field on every source event, see if it matches a known Partner in PlaceCal, and if so normalise the address and connect the two.
If there’s no match it should reject importing and make a message (”Could not import: #{address} matches no known venue. Create it?”)
Response: Place: nil, Address: copy over and normalise if possible