Bug 34817

Summary:	New framework plugin callnumber_colors.pl
Product:	Koha	Reporter:	Marcel de Rooy <m.de.rooy>
Component:	Cataloging	Assignee:	Marcel de Rooy <m.de.rooy>
Status:	Failed QA ---	QA Contact:	Testopia <testopia>
Severity:	enhancement
Priority:	P5 - low	CC:	kelly, lucas, m.de.rooy
Version:	Main
Hardware:	All
OS:	All
See Also:	https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=34860
Change sponsored?:	---	Patch complexity:	Small patch
Documentation contact:		Documentation submission:
Text to go in the release notes:		Version(s) released in:
Circulation function:
Attachments:	Bug 34817: Framework plugin callnumber_colors

Description Marcel de Rooy 2023-09-18 10:57:18 UTC

Very simple thing. Connect this to your itemcallnumber field in Administration/MARC frameworks. And when you edit the callnumber and leave the field (Change event), you will get a red or green background color telling you that the callnumber is unique (green) or not (red).
It is just meant as a visual warning. The user can still continue and save.

Technical detail: The js code calls items endpoint of REST API.

Comment 1 Marcel de Rooy 2023-09-18 12:56:17 UTC

Created attachment 155817 [details] [review]
Bug 34817: Framework plugin callnumber_colors

Test plan:
Add this to your IntranetUserCSS:
  .callnumber_green { background-color: green; } /* callnumber_colors.pl framework plugin */
  .callnumber_red { background-color: red; } /* callnumber_colors.pl framework plugin */
Goto Administration/MARC bib framework. Add callnumber_colors.pl as plugin to 952$o.
Goto Cataloguing/Edit items.
Test the plugin with a new and existing item. Test response on existing
callnumber, not existing, clearing field.

Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>

Comment 2 Kelly McElligott 2023-09-25 16:23:53 UTC

Upon testing this, I wonder, if the red/green action should be stopping the user from continuing on through the process.  Regardless if I had a new call number - green or a copy of a call number- red, it saved the item and moved on. This process was actaully super quick, like it flashed red/ green very quickly, and this could be missed.

Comment 3 Katrin Fischer 2023-09-25 17:34:57 UTC

Just a note: red / green is not good for accessibility - color blindness is very common. Could we add another visual element that helps to see the status?

Comment 4 Marcel de Rooy 2023-09-26 11:07:55 UTC

(In reply to Kelly McElligott from comment #2)
> Upon testing this, I wonder, if the red/green action should be stopping the
> user from continuing on through the process.  Regardless if I had a new call
> number - green or a copy of a call number- red, it saved the item and moved
> on. This process was actaully super quick, like it flashed red/ green very
> quickly, and this could be missed.

Thx for testing, Kelly. The idea was to alert staff about a duplicate call number but not stop them since it may well be a valid choice. (We are using duplicate call numbers in some cases.) The background should stay in that color. But if you are a mouse user and you are clicking Save, this might indeed be suboptimal. And you may need an extra alert. Still thinking about it.


(In reply to Katrin Fischer from comment #3)
> Just a note: red / green is not good for accessibility - color blindness is
> very common. Could we add another visual element that helps to see the
> status?

Hi Katrin. Another alert/popup might be handy when using mouse. And red/green can be changed via css. I now tested with lightgreen and orange.

Comment 5 Lucas Gass (lukeg) 2023-09-26 20:45:31 UTC

1. Should the user have to add their own CSS to make this work? It would be better if we defined the colors so users don't have to find/define accessible colors on their own.

2. Use aria to define/give meaning to those who are low/no vision users? 

3. Looks like a leftover debugging statement, unless you mean to keep "console.log( cn_value + ': ' + data.length );".