It would be nice to let librarians use one of several pre-filled values in the restriction comment for a manual restrictions. The values could be provided by authorised value with category "R_COMMENTS". Values could be selected although another comment could be hand-typed.
Created attachment 175912 [details] [review] Bug 38776: new "R_COMMENTS" authorized value category for manual restrictions comments Test plan : - on a patron page, add a manual restriction and fill in a comment, that needs to be typed-in - apply patch - create a new authorized value category named "R_COMMENTS" and create a couple of values with a description - return to patron page and when adding a manual restriction, on click on the input field you would be proposed the authorized values descriptions. - also you can inspect the code and see that there is a datalist element containing the list of options.
Arthur, I like the idea, but there are some issues: 1) Category name I feel "R_COMMENTS" is too general. I think we don't need to save on characters here looking at some of the other categories. What about RESTRICTION_COMMENTS? 2) Replacing free text with authorised value list This removes the option to add free text entries which might be a needed feature for libraries. I see 2 possible solutions here: a) Only display if there are existing values for the AV category. b) Allow both: selecting from the list and free text (like the reasons pull down in suggestions)
Realize this is still NEW, so you are probably still working on it, but just in case: 3) Category needs to be added to sample data (just the category, even if no sample values) 4) Database update to add the category.
Hi Katrin, Indeed this is still a work in progress :) I'll take all your remarks and make a followup. Have a nice year 2025 (and following!) Arthur
Created attachment 176160 [details] [review] Bug 38776: (QA follow-up) UI improvement + category renamed - The authorised value category was renamed from "R_COMMENTS" to a more explicit value : "RESTRICTION_COMMENTS" - It is now easier in the patron detail page to either select one of the defined value or to fill in a custom value (select "other" then type your comment).
Oups, I forgot to say it in the commit message but I've also made an atomicbug to create the authorised_value_category. I didn't fill in any default value though, because this could change from a library to another + it is not mandatory to have authorised_value for Koha to work (previous behavior preserved). This is for admin to save some librarian time by filling in some pre-defined restriction_comments frequently occurring values.
Hi, I just tested this patch (on a sandbox) I created 2 authorised values and the drop-menu displays them it also displays an 'Others' reason That works ! But, once the manual restriction added, there is only 'Indefinite' displayed on the patron's account; the reason (authorised value) and its comment (free text) aren't displayed (neither on top of this screen neither in the Restriction tab) (indefinite is linked to the expiration date (and I didn't fill that field)
I have to make a followup anyway but just demonstrating how it works. https://youtu.be/4PlaQASVeEs
Created attachment 176493 [details] [review] Bug 38776: (QA follow-up) hide the other_reason text field on page load
Hello Emmanuel, I cannot reproduce your issue :/ Can you retry after a page refresh? It is possible that the javascript is improperly loaded from your cache instead of latest version from source. Happy bug squashing with Victor + others :)
Created attachment 176496 [details] [review] Bug 38776: new "R_COMMENTS" authorized value category for manual restrictions comments Test plan : - on a patron page, add a manual restriction and fill in a comment, that needs to be typed-in - apply patch - create a new authorized value category named "R_COMMENTS" and create a couple of values with a description - return to patron page and when adding a manual restriction, on click on the input field you would be proposed the authorized values descriptions. - also you can inspect the code and see that there is a datalist element containing the list of options. Signed-off-by: Emmanuel Bétemps <e.betemps@gmail.com>
Created attachment 176497 [details] [review] Bug 38776: (QA follow-up) UI improvement + category renamed - The authorised value category was renamed from "R_COMMENTS" to a more explicit value : "RESTRICTION_COMMENTS" - It is now easier in the patron detail page to either select one of the defined value or to fill in a custom value (select "other" then type your comment). Signed-off-by: Emmanuel Bétemps <e.betemps@gmail.com>
Created attachment 176498 [details] [review] Bug 38776: (QA follow-up) hide the other_reason text field on page load Signed-off-by: Emmanuel Bétemps <e.betemps@gmail.com>
The same sandbox and same URL, the form looks correct on my PC. And on Emmanuel's PC we installed Chromium and tried there and it was also broken. Nothing on the OS (also a not too old Linux) should change how Firefox and Chromium on latest version how display basic HTML forms. It's strait up paranormal! 👽 Anyway, it's not something about the patch. Thanks for retesting.
thanks!