[BUG] Already confirmed connection cannot be replaced by alternatives

[ErHaWeb]

If a content element in the default language already has a confirmed connection in the selected non-default language and additional "Possible connections" are also recognized, the possible connections cannot be selected as an alternative to the already confirmed connection. The button with the arrow pointing to the right, which is otherwise displayed when a Possible Connection has been confirmed, is missing.

[Bunnyfield]

That's actually a feature and not a bug, because moving elements to the right is only available for elements which have not been connected yet. This is done for a reason, because you will have to break up that existing connection first, before you can attach anything else to that original element.

So if you are really shure you want to replace that element, you will have to make it an orphan first. Reattaching those elements will be possible with upcoming #7 in the "next level".

Since this is most likely not going to be changed I will close that issue.

[ErHaWeb]

An orphaned connection that was created when using the function Remove all connection information. no longer has any reference to the record of the default language and would have to be completely reassigned (as described by you).

In cases like the one described here, it would be nice if the connection information under "Possible Connection" could be retained so that it behaves like the other Possible Connections, which can then be selected as an alternative.

Imagine the following scenario:

The editor has two possible connections to choose from and selects one of the two variants in the TransFusion Connector and clicks on Save. This creates a genuine, confirmed connection.

The editor then realizes that he has selected the wrong content element. He can only undo this if he completely removes the already confirmed connection, i.e. deletes any information that allows the acceptance of a possible connection.

Should I open a new feature request "Separability of elements while retaining connection information" for this?

[Bunnyfield]

Actually the scenario is still the same and your description just confirms the reasons mentioned before:

If you find out that the decision you've made was wrong, this means, that

1. you definitely want another element
2. so the former element either has to be fully deleted
3. or kept to be assigned to another element.

There is actually no plausible reason to keep it as a possible connection for the same parent, because that decision has already been made before.

[Bunnyfield]

To explain it a bit further: The goal of the connection wizard is a fully connected set of records with no unconnected records left in the target language. Anything else would be either free or mixed mode.

So if a connection was wrong and is now going to be replaced by another possible connection, the first one needs to go, to be reconnected to another element or to be connected to a newly created parent.

[ErHaWeb]

Thank you for the explanation. From this point of view, it makes sense to me. I guess we have different basic assumptions on this point. When I opened the issue I assumed that no action in the TransFusion Connector should be irreversible.

I have editors in mind here who may not be 100% clear about every step and may want to switch back and forth between opposing possibilities without destroying connection information in the database.

In the end, there is (as far as I can see) no technical need to delete any connection information (beside l18n_parent). So that, in case of doubt, it could still be retained as an aid for subsequent scenarios.

In any case, we have definitely landed in the „feature" (not „bug") area. I would be happy if we could discuss this basic assumption again outside of this issue.