A distinct different relations type that Editors would need to pick on creation, which makes the location relation:
1. Generate links to location instead of main location of given content
2. Stay with location on swap operation
3. Be broken if location is deleted (can technically still be aware of content id, but probably would need editor to decide what best option is between changing, staying with main, or deleting relation)

—

Technical:

In legacy location relations where partly supported in:

• relation list field type (location user picked would be kept)
• xmltext for embed and link selecting specifically location relation (own location:// link in the xml format)

But not in:

• relation field type
• object relations

For the places it existed it was half baked, it would break if user deleted the location (directly or indirectly). For this reason it was removed from relation list field type in Platform stack.

Returning this feature can be done in one of two ways:

• New separate feature from content relations
• Adding a optional location field to content relations true out the system, including the db link table, so the system can realiably update content when locations are deleted

Open questions:

Q: How should this behave on Location Swap
A: Most likely location id should be kept, and content id updated.

Q: How should it behave on Location deletion
A: Relation should be removed, and data and field types should be updated.
Side: Ideally both Content and Locations should have states to signal they are being deleted so system can first mark it for deletion and do the heavy lifting of iterating content relating to it asynchronously.

Reported by larseirik.ronning@makingwaves.no