Summary: | Addbiblio shows clickable tag editor icons which do nothing | ||
---|---|---|---|
Product: | Koha | Reporter: | paxed <pasi.kallinen> |
Component: | Cataloging | Assignee: | Jonathan Druart <jonathan.druart> |
Status: | CLOSED FIXED | QA Contact: | Marcel de Rooy <m.de.rooy> |
Severity: | minor | ||
Priority: | P5 - low | CC: | jonathan.druart, lucas, m.de.rooy, martin.renvoize, nick |
Version: | Main | ||
Hardware: | All | ||
OS: | All | ||
Change sponsored?: | --- | Patch complexity: | Trivial patch |
Documentation contact: | Documentation submission: | ||
Text to go in the release notes: | Version(s) released in: |
19.05.00, 18.11.06
|
|
Circulation function: | |||
Attachments: |
Bug 21709: Replace 'no popup' plugin links with a span
Bug 21709: Replace 'no popup' plugin links with a span Bug 21709: Replace 'no popup' plugin links with a span Bug 21709: Replace 'no popup' plugin links with a span |
Description
paxed
2018-10-29 07:19:01 UTC
Please add more details how to reproduce. (In reply to Marcel de Rooy from comment #1) > Please add more details how to reproduce. Install master with defaults, go to Cataloging > New record > Default framework, try to click on the 003 or 005 tag editor icon. Contrast that with the tag editor icons of 000, 007, or 008. I think they work when clicking in the field, not all have a pop-up. Similar to the one behind dateacessioned or autobarode. So they icon can indicate extra functionality that is linked to the field. But in these cases, the icon is clickable, it just does nothing. If it did the same as clicking on the field (autofilling the data), then it would be OK. If the icon wasn't clickable, it would be OK. (Although I'd still want a visual indication without needing to move the mouse over it) Created attachment 81832 [details] [review] Bug 21709: Replace 'no popup' plugin links with a span Like that? Also I am wondering if we should not remove some classes, I do not know what is the purpose of .buttonDot <span class="buttonDot tag_editor disabled" tabindex="-1" title="Field autofilled by plugin"></a> This seems to be invalid HTML :) (In reply to Jonathan Druart from comment #7) > Like that? Also I am wondering if we should not remove some classes, I do > not know what is the purpose of .buttonDot This makes no actual difference. I still see a button that does not respond to clicks. But this is the actual design: if you do not explicitly assign a click event, it should not respond to click. (The only problem is that we have been used to some buttons that translated click to focus events.) I agree with paxed that we should see the difference right away: have a visual distinction between a real popup and just a focus action (there may be a report already for that). Only removing the button is not the solution, since we still want to alert on the focus action. It should not be that hard to define a separate class and add some css associated to it to achieve our goal. On the other hand, when we really want click to translate to focus, add three lines in the popup script. For instance for 003 in marc21_orgcode.pl: function Click$params->{id}(event) { \$('#'+event.data.id).focus(); } And now it responds to click and triggers focus.. (I still think though that it should not be the default.) The buttondot class indeed seems to be unneeded ballast. Note that we do need the buttonDot_ id. Created attachment 89379 [details] [review] Bug 21709: Replace 'no popup' plugin links with a span Test plan: Edit a bibliographic record Notice that the icons next to fields linked with a plugin can be a link or not. The browser displays a pointer or not. It will remove the ambiguity to display an icon that is clickable but does nothing when clicked. We could also have another icon to disociate both behaviors. (In reply to Marcel de Rooy from comment #9) > (In reply to Jonathan Druart from comment #7) > > Like that? Also I am wondering if we should not remove some classes, I do > > not know what is the purpose of .buttonDot > > This makes no actual difference. I still see a button that does not respond > to clicks. To me it's an improvement, the link is removed if no popup will be opened. So there is an icon but nothing to tell you it's clickable (pointer will be different). Created attachment 89390 [details] [review] Bug 21709: Replace 'no popup' plugin links with a span Test plan: Edit a bibliographic record Notice that the icons next to fields linked with a plugin can be a link or not. The browser displays a pointer or not. It will remove the ambiguity to display an icon that is clickable but does nothing when clicked. We could also have another icon to disociate both behaviors. Signed-off-by: Owen Leonard <oleonard@myacpl.org> QA: Looking here Created attachment 89524 [details] [review] Bug 21709: Replace 'no popup' plugin links with a span Test plan: Edit a bibliographic record Notice that the icons next to fields linked with a plugin can be a link or not. The browser displays a pointer or not. It will remove the ambiguity to display an icon that is clickable but does nothing when clicked. We could also have another icon to disociate both behaviors. Signed-off-by: Owen Leonard <oleonard@myacpl.org> Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl> Awesome work all! Pushed to master for 19.05 Pushed to 18.11.x for 18.11.06 backported to 18.05.x for 18.05.13 |