[7.11.24] POI update and contacts

[MizukiTemma]

Motivation

There will be such cases that a POI is updated with a new E-mail address, phone number or website and some contacts are taking those infos from the POI. What should happen in such a case?

Proposed Solution

1. Update the related contacts with the new E-mail, phone number and website of the updated POI if they are taking those fields from the POI.
   Pros: they always synchronise.
   Cons: less flexibility for users (Maybe sometimes they need to update the POI but don't want to automatically influence on (all) the contacts.)

And show a message "The followting contacts are updated: A, B, ......, Z" after successful update of the POI.

2. Do not update the related contacts (+ show an warning that they are divergent in the contact list or form). Pros: users have more control. Cons: users have to check (and adjust) the contacts by themselves.

3. Let users choose which contacts must be updated together with the POI
   Pros: more flexibility for users
   Cons: too much effort/steps for users? more technical work

Alternatives

User Story

Additional Context

Design Requirements

[david-venhoff]

One alternative would be to completely disallow users from updating email-address, phone number and website details once we land contacts. Contacts completely replace the functionality provided by these fields and we should not support two equivalent solutions to achieve the same thing.

Unfortunately we cannot write a migration that automatically creates a contact from pois with these fields, because we cannot extract the required field title. However, we could deprecate these fields. Then they would not be visible to users when they create a new poi, or when they edit an existing poi that has a linked contact. They would only be visible when a user edits a poi without a contact, but there we would prevent users from changing these fields unless they create a contact. This way, we could eventually phase-out these poi fields and at some point in the future remove the fields from the poi model.

The big advantage would be no redundancy.

[MizukiTemma]

@david-venhoff
I'm not sure we are sharing the same context. It's neither about letting users change name, address, e-mail etc of POI in the contact form nor creating a new contact automatically when creating/updatig a POI .The target scenario is as below:

1. There is a POI with an website "some-website.com"
2. There is a contact, which is related to this POI and inheriting the website URL.
3. Now an user opened this POI, gave a new website "new-website.com" and saved it.
4. The website field of the contact must be changed to "new-website.com", when website_from_location is True

[david-venhoff]

3. Now an user opened this POI, gave a new website "new-website.com" and saved it.

Well, if we don't let users change the email, etc. of pois, then point 3 cannot apply and we don't have this problem.

[PeterNerlich]

@MizukiTemma I'm wondering whether your and my current ideas of the relation between pois and contacts differ. My idea is that when a detail in the contact model is marked as Use the detail from the linked POI, then any value possibly saved for the detail on the contact itself is irrelevant and will also not be used by the system – until the checkbox gets unchecked, that is.
I get the impression that maybe your idea is different, and in that case we should drill down on that difference and ensure we are on the same page and try to achieve the same thing. It sounds a bit like you imagine the POI detail getting copied to the field in the contact object whenever it is edited (and when the poi is updated), and then used from the contact model wherever it is to be included in page/… content. If my impression is correct or you are confused by my explanation of my mental model, let's talk about it.

[MizukiTemma]

@PeterNerlich
Oooo :man-facepalming: Yes, I imagined copying the value of POI when the checkbox is set, not reading from the POI. Nice that this was now found 😁

We anyway need a discussion about those contact info fields, including the idea to remove those fields from POI and move this functionality to contact objects.