[Bug]: Deleting an address from a partner will cause importer issues with any calendar with that partner set as a default location

[kimadactyl]

related: #838

depends on: #2208

Some implementation suggestions (needs further discussion):

• when there is no address and the calendar importer is unable to run, an error message explaining why this is is shown to the users

or

• Before calendar requests events from the remote source, check if the location is still present and valid and stop the import job if not. Put calendar in a fault state and give the user a helpful message.

or

• If no address is attached to a partner, when using a strategy that relies on this address, default to a no address strategy instead when importing events

or

• fix the strategies so that they can cope with a partner that has no address - this probably shouldn't be a dealbreaker?

[ivan-kocienski-gfsc]

Need to decide what should happen:

• stop user removing address on partner that has dependent calendars
• check importer calendar that is in this configuration that if it is attached to a partner with a missing address stop the import
• something else?

[r-ferrier]

Have tried this out and it does break, but in a way that is not impossible to understand for a user. Nothing breaks when the address is removed, but the 'default location' that was previously set here vanishes.

Then, when the importer runs, it informs you that events could not be added because 'No place or address could be created or found for the event location'.

The information that follows this is less helpful - it says the address attached to the event, not the address of the default location, but this sort of makes sense because we've deleted that address and I guess it's basically trying to check against nothing. I think we should just change the error message here so that if no location is found, we say something more helpful about why this is broken, eg 'There is no address set for this location, please choose a different location and try again'.

[r-ferrier]

leaving to discuss tomorrow AM