https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32748 --- Comment #1 from Katrin Fischer <katrin.fischer@bsz-bw.de> --- The goal should be to have a 'keep current' option like we have for funds on the receive screen that you are not allowed to use. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32748 Thibaud Guillot <thibaud.guillot@biblibre.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |thibaud.guillot@biblibre.co | |m --- Comment #2 from Thibaud Guillot <thibaud.guillot@biblibre.com> --- Hello Katrin, I've worked on this recently, but I don't know how to deal with this new value in dropdown. Should the form entry be disabled to prevent value change by another library? Because this is the real risk in the end. Note that there is also the same kind of behavior on serials, on location input. I am curious to have the opinion of the community on these behaviors. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32748 Thibaud Guillot <thibaud.guillot@biblibre.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |Needs Signoff -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32748 Thibaud Guillot <thibaud.guillot@biblibre.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|koha-bugs@lists.koha-commun |thibaud.guillot@biblibre.co |ity.org |m -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32748 --- Comment #5 from Michaela Sieber <michaela.sieber@kit.edu> --- (In reply to Thibaud Guillot from comment #4)

Created attachment 148409 [details] [review] Bug 32748: Prevent data erasing when editing item This patch add current value to the dropdown list even if it comes from an authorized value of another library.

Merci beaucoup Thibaud! Everything works as expected. I tested editing existing items and adding new items with different libraries for item type Computer Files (=CF) : 1 library limitation (Fairfield) Authorized values CCODE Non-fiction (=NFIC) : 2 library limitations (Centerville, Franklin) LOC Audio visual (=AV) : 1 library limitation (Institut Protestant de Théologie) in Biblibre sandbox b32748. -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32748 Michaela Sieber <michaela.sieber@kit.edu> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Needs Signoff |Signed Off -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32748 Jonathan Druart <jonathan.druart+koha@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Signed Off |Failed QA CC| |jonathan.druart+koha@gmail. | |com --- Comment #8 from Jonathan Druart <jonathan.druart+koha@gmail.com> --- We need to keep the same behaviour as bug 31422 and add the tooltip in my opinion. Also adding one more query per AV is counter productive here, given all the work we made to cache things... -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32748 Thibaud Guillot <thibaud.guillot@biblibre.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Failed QA |Needs Signoff -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32748 --- Comment #11 from Thibaud Guillot <thibaud.guillot@biblibre.com> --- Hello, I followed your advice to rework the patch to change the behavior of the GetAuthorisedValues function and then use the values obtained to target authorised values from other librairies. I have however the problem concerning the icon that I can't see :-/ (if anyone has an idea ?) I submit you this patch to know if I'm going in the right direction. Thanks for your future feedbacks -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32748 mathieu saby <mathsabypro@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |mathsabypro@gmail.com --- Comment #13 from mathieu saby <mathsabypro@gmail.com> --- Hi We asked Biblibre to fix that bug a few monthes ago so I would like to add some comments from a librarian point of view. I am not completely sure of the predicted behavior of the patch, but please consider this situation : We have 2 libraries: - the library A has only 2 locations LOCA-1 and LOCA-2 - the library B has only 2 locations LOCB-1 and LOCB-2. An item's homebranch is library A, location LOCA-1. The librarian is connected to library B The location LOCA-1 should be preserved when the librarian edits the item in order to change an other item field. But he must not be allowed to change the location to LOCB-1 or LOCB-2. It would result in a data inconsistency because those location are not valid for Library A. Is it the behavior you are planning ? -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32748 --- Comment #15 from mathieu saby <mathsabypro@gmail.com> --- Yes, the data loss is a nasty bug and must be fixed. Perhaps my embarrassment arises from the fact that Koha relies exclusively on the librarian's connection library to filter the possible locations. Most of the time this is not a problem, but if the item's homebranch is different from the connexion library, it leads to a behavior that can be inconvenient or surprising. One could imagine that Koha relies dynamically on the homebranch defined in the form to determine the possible locations, like some other ILS. This has not been the initial choice of the community, but do you think it could be worth thinking about (in an other bug...) ? -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32748 --- Comment #17 from Katrin Fischer <katrin.fischer@bsz-bw.de> --- (In reply to Jonathan Druart from comment #16)

Failing QA for comment 12. Thibaud, avoid GROUP_CONCAT, and just don't display the libraries from where the value is limited.

Also you should cache using the branchcode in the cache key, or you will get random wrong results.

Maybe to explain: GROUP_CONCAT creates an issue with <strict_sql_modes>1</strict_sql_modes>. If you have turned that off in koha-conf.xml you'll not see the error until you turn it back on. -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32748 Thibaud Guillot <thibaud.guillot@biblibre.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #150155|0 |1 is obsolete| | --- Comment #18 from Thibaud Guillot <thibaud.guillot@biblibre.com> --- Created attachment 151989 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=151989&action=edit Bug 32748: Prevent data erasing when editing items When we set an authorised value linked to one library, users who do not belong to this library do not get the value and can therefore overwrite it. This patch add current value to the dropdown list even if it comes from an authorized value of another library. Test plan : 1) Edit an item with one of these fields has an authorized value from another library. 2) See that you don't get this value on 'edit' 3) Apply this patch 4) Refresh and do step 1 5) Now you have the value in dropdown list and a tooltip info -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32748 --- Comment #20 from Jonathan Druart <jonathan.druart+koha@gmail.com> --- (In reply to Thibaud Guillot from comment #19)

Jonathan : What do you mean by adding the branchcode into the cache key? The branchcode from which the VAs originate is not accessible until the cached string is defined. Why should I get random results? Thanks for the clarification

Hum forget that, branch_limit is part of the cache key. I cannot remember what I meant but that does not seem correct. -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32748 --- Comment #22 from Thibaud Guillot <thibaud.guillot@biblibre.com> --- (In reply to Michaela Sieber from comment #21)

(In reply to Thibaud Guillot from comment #18)

...

Created attachment 151989 [details] [review] [review] Bug 32748: Prevent data erasing when editing items

Sorry, but Patch doesn't apply :/

it was possible to select location and collection (authorized values) of other Libraries and the dropdown was not limited.

And there is a new problem when an item type is limited to a library. If you edit the item and you are logged in with another library there is a message in the item type field "The current value CF is not configured for the authorised value category controlling this subfield" which I guess is very confusing for end users.

You can check it here: https://staff-b32748.sandboxes.biblibre.eu/cgi-bin/koha/cataloguing/additem. pl?op=edititem&biblionumber=58&itemnumber=973&searchid=#edititem

I tested editing existing items and adding new items with different libraries for

item type Computer Files (=CF) : 1 library limitation (Fairfield)

Authorized values CCODE Non-fiction (=NFIC) : 2 library limitations (Centerville, Franklin)

LOC Audio visual (=AV) : 1 library limitation (Institut Protestant de Théologie)

Hello Michaela, Thanks for your test and feedback, the case you specify is already pushed in master, my code doesn't add this message. I can understand the confusion, but should we fix this message on another bz or am I proposing a correction here? -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32748 Katrin Fischer <katrin.fischer@bsz-bw.de> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #151989|0 |1 is obsolete| | --- Comment #23 from Katrin Fischer <katrin.fischer@bsz-bw.de> --- Created attachment 154039 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=154039&action=edit Bug 32748: Prevent data erasing when editing items When we set an authorised value linked to one library, users who do not belong to this library do not get the value and can therefore overwrite it. This patch add current value to the dropdown list even if it comes from an authorized value of another library. Test plan : 1) Edit an item with one of these fields has an authorized value from another library. 2) See that you don't get this value on 'edit' 3) Apply this patch 4) Refresh and do step 1 5) Now you have the value in dropdown list and a tooltip info -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32748 --- Comment #25 from Katrin Fischer <katrin.fischer@bsz-bw.de> --- Created attachment 154041 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=154041&action=edit Bug 32748: (follow-up) Perltidy -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32748 Katrin Fischer <katrin.fischer@bsz-bw.de> changed: What |Removed |Added ---------------------------------------------------------------------------- Depends on| |19361 --- Comment #27 from Katrin Fischer <katrin.fischer@bsz-bw.de> --- Trying to have a look at this with a set of fresh eyes :) I've written some follow-ups for coding guidelines and to get the QA test tools green, but the behavior is not quite right yet and this will need another look. Test setup: * CCODE: REF - amended description with -Fairfield and limited to Fairfield library * LOC: AV - amended description, limited to Fairfield * Itemtype: BKS - amended description, limited to Fairfield * Updated Henry from Midway to only have catalog and cataloguing permissions * I am testing with an item that CCODE = REF and LOC = NOT AV, itemtype BKS WITHOUT PATCH / BEFORE 1) Edit item form * Henry (Midway) * CCODE of the item is REF: it shows in the pull down, but marked as: Not an authorised value /!\ I believe this is a separate bug caused by bug 19361. It should not show as non-existing, but as limited. Same for itemtype. * LOC: AV is missing from the list. * BK: (not an authorised value) * Superlibrarian (Centerville) * CCODE of the item if REF: Not an authorised value. * LOC: AV is missing. * Itype: BK (not an authorised value) = Behaviour is the same for superlibrarians and users with limited permissions. * Superlibrarian (Fairfield, login library) * CCODE, LOC and itype display normally. 2) Edit record form * Itype is not limited by branch and visible for Henry and superlibrarian. /!\ A different/new bug? WITH PATCHES / AFTER 1) Edit item form * Henry (Midway) * (improved) CCODE: It now shows with description and warning sign. * (wrong) LOC: The limited value is now in the pull down list. It should not be as the item is not using it. * (unchanged, wrong) BK: (not an authorised value). This should show the same as CCODE. * Superlibrarian (Fairfield) * (unchanged) CCODE, LOC and itype display normally. 2) Edit record form * (unchanged) Itype is not limited by branch and visible for Henry and superlibrarian. SUMMARY I think we need to fix 2 things: * The AV should only display in the list, if it's already used by the item. Otherwise it should still remain hidden. This is the behaviour we have for category codes on the patron edit forms. * It looks like the code doesn't take the 'false' AV like itemtype into account, but it should. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19361 [Bug 19361] Linking an authorised value category to a field in a framework can lose data -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32748 Katrin Fischer <katrin.fischer@bsz-bw.de> changed: What |Removed |Added ---------------------------------------------------------------------------- See Also|https://bugs.koha-community | |.org/bugzilla3/show_bug.cgi | |?id=35176 | -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32748 --- Comment #29 from Katrin Fischer <katrin.fischer@bsz-bw.de> --- (In reply to Thibaud Guillot from comment #28)

Hi Katrin,

Sorry for the delay in my reply. I've gone back over the code a bit, concerning the presence of the value if it's not the current value, I've taken a look at the form for modifying the categorycode of a borrower and the value, even if it's limited to a branch, does appear in the list...

That should not be the case. I quickly retested: * My user's login branch and home library is: Centerville * Patron category "B - Board" is limited to Franklin * Create a new patron: Board doesn't show * Edit an existing patron with another patron category: Board doesn't show * Edit a patron with Board category: Board appears in the list of options (but the nice little icon and text have moved all the way to the left... maybe with the staff re-design. See bug 31422) Another area where the "keep current" is implemented really nicely is funds. If you receive an order with a fund you are not allowed to use for ordering, it will still show up in the list on receive and be marked as "current". To see this, something like this should work: * Create an order line with using fund X * Set the fund to be limited by library * set the fund to be owned by a library that is not yours * Make sure your user is not superlibrarian and doesn't have budget_manage_all * Receive the order...

maybe it's a recent patch, I seemed to have seen a few things that dealt with this but I can't find them :/

Could we add the disabled attribute to the entry to display it all the same, or should we stick with "hidden"?

One big motivation for libraries to use library limitations is 'shrinking the list' for better usability. So yes, we do want to hide and only display what is absolutely necessary.

On the other hand, I don't understand your sentence "It looks like the code doesn't take the 'false' AV like itemtype into account, but it should." I'm calling the original GetAuthorisedValues function with an extra parameter, but it didn't retrieve the basic itemtypes, so I'd like to ask you to clarify this.

I think maybe we could deal with this separately as it might be a different part of the code? What I meant is that when setting up the item form in the bibliographic framework, you will set up the authorised values "itemtypes" and "branches" to create the item type and home and holding branch pull downs. Re-thinking this, we could deal with these separately I think - especially since only itemtypes are 'library limitable'. -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32748 --- Comment #31 from Mathieu Saby <mathsabypro@gmail.com> --- We had a local patch for (more or less) fixing that bug, but I thought the problem was resolved for everbody... I'm surprised that more libraries aren't complaining about current behavior. -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32748 Thibaud Guillot (thibaud_g) <thibaud.guillot@biblibre.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #154039|0 |1 is obsolete| | --- Comment #33 from Thibaud Guillot (thibaud_g) <thibaud.guillot@biblibre.com> --- Created attachment 186006 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=186006&action=edit Bug 32748: Prevent data erasing when editing items When we set an authorised value linked to one library, users who do not belong to this library do not get the value and can therefore overwrite it. This patch add current value to the dropdown list even if it comes from an authorized value of another library. Test plan : 1) Edit an item with one of these fields has an authorized value from another library. 2) See that you don't get this value on 'edit' 3) Apply this patch 4) Refresh and do step 1 5) Now you have the value in dropdown list and a tooltip info -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32748 Thibaud Guillot (thibaud_g) <thibaud.guillot@biblibre.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #154041|0 |1 is obsolete| | --- Comment #35 from Thibaud Guillot (thibaud_g) <thibaud.guillot@biblibre.com> --- Created attachment 186008 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=186008&action=edit Bug 32748: (follow-up) Perltidy -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32748 Thibaud Guillot (thibaud_g) <thibaud.guillot@biblibre.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Failed QA |Needs Signoff -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32748 --- Comment #37 from Thibaud Guillot (thibaud_g) <thibaud.guillot@biblibre.com> --- Created attachment 186303 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=186303&action=edit Bug 32748: (follow-up) Fix list behavior if AV is restricted and add itemtype restricted values -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32748 --- Comment #38 from Thibaud Guillot (thibaud_g) <thibaud.guillot@biblibre.com> --- Created attachment 186307 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=186307&action=edit Bug 32748: Fix item edition when authorised values is restricted When we set an authorised value linked to one library, users who do not belong to this library do not get the value and can therefore overwrite it. This patch add current value to the dropdown list even if it comes from an authorized value of another library. Test plan : 1) Edit an item with one of these fields has an authorized value from another library. 2) On 'edit' you will see AV but with '(Not an authorised value)' string and a warn 3) Apply this patch 4) Refresh page and edit item again 5) Now if the authorised value belongs to another lib and is the current value, you will see it with a tooltip and a warn. But if there are authorised values restricted to another lib and isn't current value, normally it will be not present in the option list. Sponsored-by: BibLibre -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32748 --- Comment #40 from Mathieu Saby <mathsabypro@gmail.com> --- On a sandbox, I limited a location, a ccode, a "lost" value, and an item type to the Centerville library. I connected to another library. I tried to edit items where the location, ccode, lost value and item type limited to Centerville were used. An alert was visible in each field (a "work" icon and the message "this value is limited to other libraries"). I modified the items anyway (by changing their callnumber), and the Centerville-limited values were preserved. Therefore, there is no longer any data loss, and I sign off. But beyond fixing this long-standing bug, I remain convinced that the way Koha handles value limitations for libraries is inefficient and problematic, particularly for libraries belonging to networks where document processing is centralized. Even though there is no longer any data loss, it is still very easy to enter an invalid value for a given library without any warning (imagine: I work at the central library, I have to create a item for annex1, then for annex2, etc. I need to change my connection site between each item so that the value limits specific to annex1 and annex2 are applied in the form!) -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32748 --- Comment #42 from OpenFifth Sandboxes <sandboxes@openfifth.co.uk> --- Created attachment 186313 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=186313&action=edit Bug 32748: (follow-up) Fix terminology: branches > libraries Signed-off-by: Mathieu Saby <mathsabypro@gmail.com> -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32748 Mathieu Saby <mathsabypro@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Needs Signoff |Signed Off -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32748 OpenFifth Sandboxes <sandboxes@openfifth.co.uk> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #186313|0 |1 is obsolete| | --- Comment #45 from OpenFifth Sandboxes <sandboxes@openfifth.co.uk> --- Created attachment 186316 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=186316&action=edit Bug 32748: (follow-up) Fix terminology: branches > libraries Signed-off-by: Mathieu Saby <mathsabypro@gmail.com> -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32748 --- Comment #47 from Mathieu Saby <mathsabypro@gmail.com> --- Not sure if I managed to sign it off with the sandbox. At first only 1 patch appeared in bugzilla, so I signed 1 patch with the sandbox. Then a 2d patch appeared, so I tried to signed the 2 patches. Then a 3rd patch appeard, and now a 4th. How many patch need to be signed off? -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32748 Thibaud Guillot (thibaud_g) <thibaud.guillot@biblibre.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Patch doesn't apply |Needs Signoff -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32748 --- Comment #50 from Thibaud Guillot (thibaud_g) <thibaud.guillot@biblibre.com> --- Hi, Thanks for feedback, I rebased it -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32748 Thibaud Guillot (thibaud_g) <thibaud.guillot@biblibre.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #188549|0 |1 is obsolete| | --- Comment #52 from Thibaud Guillot (thibaud_g) <thibaud.guillot@biblibre.com> --- Created attachment 188552 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=188552&action=edit Bug 32748: Fix item edition when authorised values is restricted When we set an authorised value linked to one library, users who do not belong to this library do not get the value and can therefore overwrite it. This patch add current value to the dropdown list even if it comes from an authorized value of another library. Test plan : 1) Edit an item with one of these fields has an authorized value from another library. 2) On 'edit' you will see AV but with '(Not an authorised value)' string and a warn 3) Apply this patch 4) Refresh page and edit item again 5) Now if the authorised value belongs to another lib and is the current value, you will see it with a tooltip and a warn. But if there are authorised values restricted to another lib and isn't current value, normally it will be not present in the option list. Sponsored-by: BibLibre Signed-off-by: Mathieu Saby <mathsabypro@gmail.com> -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32748 Thibaud Guillot (thibaud_g) <thibaud.guillot@biblibre.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Needs Signoff |Signed Off -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32748 Lisette Scheer <lisette@bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #188552|0 |1 is obsolete| | --- Comment #54 from Lisette Scheer <lisette@bywatersolutions.com> --- Created attachment 189655 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=189655&action=edit Bug 32748: Fix item edition when authorised values is restricted Worked great and I'm looking forward to seeing this fixed. When we set an authorised value linked to one library, users who do not belong to this library do not get the value and can therefore overwrite it. This patch add current value to the dropdown list even if it comes from an authorized value of another library. Test plan : 1) Edit an item with one of these fields has an authorized value from another library. 2) On 'edit' you will see AV but with '(Not an authorised value)' string and a warn 3) Apply this patch 4) Refresh page and edit item again 5) Now if the authorised value belongs to another lib and is the current value, you will see it with a tooltip and a warn. But if there are authorised values restricted to another lib and isn't current value, normally it will be not present in the option list. Sponsored-by: BibLibre Signed-off-by: Mathieu Saby <mathsabypro@gmail.com> Signed-off-by: Lisette Scheer <lisette@bywatersolutions.com> -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32748 Lisette Scheer <lisette@bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- QA Contact|testopia@bugs.koha-communit |lisette@bywatersolutions.co |y.org |m CC| |lisette@bywatersolutions.co | |m Keywords| |release-notes-needed -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32748 Thibaud Guillot (thibaud_g) <thibaud.guillot@biblibre.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Failed QA |Signed Off -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32748 --- Comment #58 from Thibaud Guillot (thibaud_g) <thibaud.guillot@biblibre.com> --- Created attachment 203507 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=203507&action=edit Bug 32748: (QA follow-up) Fix spelling and tidy -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32748 --- Comment #60 from Thibaud Guillot (thibaud_g) <thibaud.guillot@biblibre.com> --- (In reply to Jonathan Druart from comment #56)

(In reply to Thibaud Guillot (thibaud_g) from comment #19)

...

Hello everyone,

I followed your advices and removed the display of the branchcode where the values come from (and therefore the GROUP_CONCAT). I hope it can be tested by as many people as possible :-)

Jonathan : What do you mean by adding the branchcode into the cache key? The branchcode from which the VAs originate is not accessible until the cached string is defined. Why should I get random results? Thanks for the clarification

When I wrote that no-limit was part of the cache key (https://bugs.koha-community.org/bugzilla3/attachment. cgi?id=151989&action=edit) In the last version of the patch it's no longer there. Is there a reason for that?

Also there are modification to 2 different sub/methods but no tests.

Hi Jonathan, You were right, and my earlier reply misunderstood the question — sorry for the confusion. I fixed this and add some tests -- You are receiving this mail because: You are watching all bug changes.