Multiple registration does not work

[koehlerannkathrin]

In Clever-Reach, multiple registration can be activated for a form. The existing data of a recipient will be overwritten when a new registration is made.

Unfortunately, re-registration does not work with this package. This message is displayed when a new registration is made via the Clever-Reach form:

This e-mail address is already in the list of recipients. (Translation ID: 1504541582)

This message is displayed in the browser's dev tools: subscribe 400

The new request of the form is not processed and therefore the data is not updated.

Is there a way to add this functionality?

[Nikdro]

Hi @koehlerannkathrin,

thanks for your issue and the idea it brings into this package.
That feature in CleverReach was completely new to me. Seems like our customers aren't using it, otherwise this should have been a problem here, too.

The current architecture of this packages is using Flow's validators to check all POST-ed data. Before submitting the user to a list, there is a check, if the user isn't already added. In that Validator (ReceiverNotExistsInGroupValidator), there is no information about the sign-up form (yet).
So my first idea was to ask CR's API, if that "double subscription" is allowed on the current form. But after a quick check, it seems like there is no information about that in the api.

Now I started a thread about that in CleverReach's Community. Hoping, that I missed something or we can maybe get that information via API in the future. See https://support.cleverreach.de/hc/de/community/posts/18280388814994-Formular-Einstellungen-%C3%BCber-API-Abfragen

Otherwise I've got 2 quick Ideas for a workaround:

1. Makeing it configurable in Neos.
This should be manageable in terms of effort, but has the disadvantage that this setting has to be made in two places (CleverReach and Neos).
I also know that many people only use our package as an "ApiClient" and rely on their own NodeTypes. This may then cause problems with backward compatibility.

2. Removing that Validator completely
The cleanest way would probably be to remove the validator completely and simply try to send the data directly to the API. If the option is not activated and the user is already signed-up to that list, an error occurs that we could catch.
Unfortunately, this changes the previous behavior of the package. So it is also a limitation in backward compatibility.

Accordingly, I'm still not quite sure how exactly we should solve the whole thing. I'm currently leaning towards option 2, but perhaps something will arise of my request to CleverReach. I would give it a few days for now.

Please let me know what you would prefer or what works best for you. Thank you!

[koehlerannkathrin]

Hi @Nikdro ,
thank you very much for your answer!
Too bad there is no data in the API that can be used for this.

The solution approaches sound very interesting. The compatibility aspect is of course very important. In fact, the approach from solution two sounds good. However, it would of course be good if the rest of the behavior could remain the same. I am also hoping for an answer from Clever Reach and from you! Perhaps we will be able to map this behavior in the future.