Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[4.0] Different behaviour for adding an associated item in multilingual associations #25646

Open
lavipr opened this issue Jul 19, 2019 · 9 comments

Comments

@lavipr
Copy link
Contributor

lavipr commented Jul 19, 2019

Steps to reproduce the issue

Have at least 3 languages installed.
Enable the languagefilter plugin with item associations enabled or install the multisample language data.

Create an association (if not created yet) with all 3 languages.

a) in Multilingual associations

  • Select an item - another than the one with all 3 languages associated - as reference and a languages as target (It doesn't matter if there is already an association or not)
    screen shot 2019-07-19 at 17 40 27
  • Click on "Select Target" and select an item that is associated with other items (also with a third language, that is not the reference language).
    screen shot 2019-07-19 at 17 41 54
    -> Save

Revert the changes from a) to compare with b)

b) In components that support associations

  • Select an item to edit (e.g. in Articles View)
    screen shot 2019-07-19 at 17 49 25
  • Go to the associations tab and select an associated item as in a) (In this modal we can't see if an item is associated yet or not)
    screen shot 2019-07-19 at 17 52 37
    -> Save

Expected result

a) Just the selected item has been moved from the old association to the new one.

Actual result

a) doesn't work as expected:
The selected target item has been associated with the reference, but also the other associated items except the one in the reference language has been associated. So the old association doesn't exist anymore. Even when the item in the third language has been associated before, so the one from the other association doesn't get moved to the new one, the old association gets deleted.
screen shot 2019-07-19 at 17 44 10

b) works like expected: Just the selected item has been moved from the old association to the new one.
screen shot 2019-07-19 at 17 53 10

Additional comments

So the behaviour in a) is confusing. When an item is selected, it is expected that only this item will be added.
Even more confusing is when a) and b) behave differently, so I think a) is a bug.

Side Note: From b) we can achieve the same result as in a) if the button propagate is used.

Edit:
As I noticed right now after finding this #21250, before the propagate button has been introduced, the behaviour was always like in a).
So since we have two different behaviors, wouldn't it be better to proceed constantly and adapt this behaviour to multilingual associations as well?

@ghost
Copy link

ghost commented Jul 20, 2019

@infograf768 your opinion?

@infograf768
Copy link
Member

not on desktop right now. will look later

@infograf768
Copy link
Member

At this time, I have a more important bug in com_associations for articles:
The category field is not always filled, sometimes for the reference, sometimes for the target, sometimes for both...
Similar issue for categories with the parent field.

It is unrelated to the issue posted here but needs solving before looking further into this.

@infograf768
Copy link
Member

See #25672

@infograf768
Copy link
Member

The bugs I was referring to above are now solved
#25676
and for now in 3.9.11 (would have to be added to 4.0 when @wilsonge will get there)
#25704

Let's now try to fix the original issue here.
Any proposal?

@robbiejackson
Copy link

In case a) (Multilingual Associations) I think we get the same result as in case b) whenever we press Save Reference, rather than Save Target.

In Multilingual Associations whenever we're connecting 2 items each of which has existing associations, then conflicts will arise, as can be seen for Articles by clicking on the Associations tab in both the Reference and Target panes. So in such circumstances users would have to select the set of Associations they'd want to keep by either clicking Save Reference or Save Target.

I think that if we change the behaviour of the form here then some users are going to complain because it then wouldn't work the way they were used to.

It might be better to identify this sort of situation, and if a conflict is likely to arise, then prompt the user to view the associations in the Reference and Target, and select Save Reference or Save Target depending on what set of associations they wanted to save.

@infograf768
Copy link
Member

@lavipr
What you think?

@lavipr
Copy link
Contributor Author

lavipr commented Aug 7, 2019

I didn't even think about the possibility that there might be a difference between reference and target when saving.

So I summarized it again for understanding: The two possibilities to associate items from different associations with each other are available in a) the multilingual association component as well as in b) components that support multilingual associations. In b), initially only the item is extracted from another association. This is achieved in a) by saving the reference. If the other entries are also to be moved over, "propagate" can be made in b) and in a) via "Save target".

"It might be better to identify this sort of situation, and if a conflict is likely to arise, then prompt the user to view the associations in the Reference and Target, and select Save Reference or Save Target depending on what set of associations they wanted to save."
I think for users who don't know this procedure yet, at least one hint that there are different possibilities is missing. Maybe a good place to display the hint would be within the modal window when selecting an item? The hint might be included in it, not a popup that can be clicked away.


This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/25646.

@richard67
Copy link
Member

@infograf768 Any idea how to continue with this issue?

@Hackwar Hackwar added the bug label Feb 19, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

6 participants