Closed marcemarc closed 2 years ago
Hello Marc,
Good day to you 😄 I'll take a look, reproduce and comment or label accordingly.
Emma
Hey @marcemarc,
Yep! This is a bug and it's possible to reproduce this in the latest release, 8.11.1. I will pop an up-for-grabs label on it as you've given us plenty to work with here.
Emma
Hi @marcemarc,
We're writing to let you know that we would love some help with this issue. We feel that this issue is ideal to flag for a community member to work on it. Once flagged here, folk looking for issues to work on will know to look at yours. Of course, please feel free work on this yourself ;-). If there are any changes to this status, we'll be sure to let you know.
For more information about issues and states, have a look at this blog post
Thanks muchly, from your friendly Umbraco GitHub bot :-)
This seems to be similar to the issue I reported here using a simple toggle, but a general issue because we have for
attribute on property label while the editor has id
attribute using property alias. We should probably cover the label with an overlay or/and prevent the the click event om the label. https://github.com/umbraco/Umbraco-CMS/issues/9676
Yes, the label extends the target for the form control it is linked to by the 'for' attribute.
So a click on the label = a click on the button.
The trickyness i think is the property editor doesn't appreciate it's in a disabled state... Which makes it difficult to check this state when the label triggers the ng-click event of the button..
The other thought is does the 'add' button need to have the id of the property alias? Eg if the whole editor had a wrapping element with id matching the property alias and the add button had id: btn-{{editor. alias}}... That would stop the label triggering ng-click (i think) - but in a non variant scenario would it make it less accessible? eg would clicking the label pass focus to the editor sufficiently? - or should the label be somehow rendered differently in this situation?
Hiya @marcemarc,
Just wanted to let you know that we noticed that this issue got a bit stale and might not be relevant any more.
We will close this issue for now but we're happy to open it up again if you think it's still relevant (for example: it's a feature request that's not yet implemented, or it's a bug that's not yet been fixed).
To open it this issue up again, you can write @umbrabot still relevant
in a new comment as the first line. It would be super helpful for us if on the next line you could let us know why you think it's still relevant.
For example:
@umbrabot still relevant This bug can still be reproduced in version
x.y.z
This will reopen the issue in the next few hours.
Thanks, from your friendly Umbraco GitHub bot :robot: :slightly_smiling_face:
I have a content picker property on a Document Type that is allowed to vary by language
The content picker itself, isn't allowed to vary by content
So items can only be picked on the default language.
When an editor views the variant, the picked items are greyed out as expected, and the 'Add' button cannot be clicked...
... however if the editor clicks the 'label' for the property editor, it does actually trigger the opening up of the dialog to pick items...
animated explanation:
Umbraco version
8.10.1
Reproduction
In an umbraco site with mulitple languages
Create a Document Type that can vary by content
Create a Content Picker Property that picks content and does not vary by content.
Pick the items on the Default language, switch to a language variant, the picked items should be greyed out - click on the label for the greyed out property editor, you'll see the option to pick content - when you shouldn't!
Expected result
I'd expect clicking on the label would change the mouse pointer to be a no entry sign, and no dialog should be displayed for picking content
Actual result
Editors feel like they can pick content here for their variant - but that is not the case, we do not want to allow editors to pick content.