---- Reported by nengard@gmail.com 2009-12-14 14:53:44 ---- On the design front for this feature, I think that all of the fields should be blank before you choose your changes - so the current and permanent location pull downs should be selected on NOTHING before hand - otherwise it's too easy to change the location. CHAT: [09:51] <nengard> on the design front - I think that all of the fields should be blank before you choose your changes - so the current and permanent location pull downs should be selected on NOTHING before hand - otherwise it's too easy to change the location [09:52] <nicomo> ++ [09:52] <nengard> I'll put that in as an enhancement [09:52] <nicomo> please open a ticket for that -> matthias.meusburger@biblibre.com ---- Additional Comments From nicolas.morin@biblibre.com 2009-12-18 15:33:00 ---- Currently, the additems.pl script, when a value is mandatory, automatically positions the field on the 1st member of the list. That was initially meant to be a feature when, I think, there wasn't any opportunity to define a "default" value for the field. Now that there is, I propose that we simply remove this bit and display dropdowns for mandatory fields the same way we display dropdowns for other fields. -> line 439: push @authorised_values, "" unless ( $tagslib->{$tag}->{$subfield}->{mandatory} ); ---- Additional Comments From nengard@gmail.com 2009-12-18 15:41:34 ---- But in the case of this particular form choosing a library isn't mandatory - you only want to choose a library if you are changing the library that the items is at. Right? ---- Additional Comments From nengard@gmail.com 2010-02-12 16:11:32 ---- This is related to: Bug - 4172 -- they don't depend on each other so I didn't put it in that field. ---- Additional Comments From wizzyrea@gmail.com 2010-02-19 20:35:52 ---- This is still an issue, confirmed by NEKLS, on DB rev. 124. ---- Additional Comments From nengard@gmail.com 2010-05-03 17:05:05 ---- This is partially fixed by this commit: commit 4b027bc4c9d9b33238ff67bd6cab6ec1667cb416 Author: Matthias Meusburger <matthias.meusburger@biblibre.com> Date: Wed Mar 10 22:26:15 2010 +0100 MT2527 : Adds default empty value for branches when batch modifying items (so they are not modified by mistake) I suggest one other change - blank should be selected by default so that everything is blank when you start. ---- Additional Comments From oleonard@myacpl.org 2010-05-04 16:59:39 ---- Because of the potential for loss of data I think the severity of the bug should be raised. --- Bug imported by chris@bigballofwax.co.nz 2010-05-21 01:20 UTC --- This bug was previously known as _bug_ 3916 at http://bugs.koha.org/cgi-bin/bugzilla3/show_bug.cgi?id=3916 Actual time not defined. Setting to 0.0 CC member nicolas.morin@biblibre.com does not have an account here
upgrading again because you cannot use this tool as it stands - which I believe is the definition of a blocker. If I want to edit items in multiple branches this tool will change the branch on all of the items to the same branch because there is no blank default for that field.
You are right. I am working on that at the moment. Fact is that it is linked to GetBranchesLoop which returns selected on the user branch... Which in that case is NOT what user expects.
Created attachment 2263 [details] [review] patch proposed for branches.
Patch pushed. Please test and close.
There is still one pull down left - the classification scheme and then we're all set.
(In reply to comment #5) > There is still one pull down left - the classification scheme and then we're > all set. Pushed fix for this. Please test and close.
Tested, this has been resolved. Will add a new enhancement bug to note the fact that you can't "unset" values using this tool (example: lost to NOT LOST).
Proposing a follow-up in order that ALL fields with pull down have an empty value selected as the default, even if the field is mandatory.
Created attachment 7650 [details] [review] Adding default empty value on ALL pull do lists
Sophie, Doesn't the checkbox serve the same purpose? Is there an additional use case that makes this new patch necessary? Liz The patch works, btw, I'll sign off on it but I'm not certain it's strictly *necessary*. Feel free to convince me. :)
Created attachment 7669 [details] [review] [Signed Off] Bug 3916 [follow-up] : Adding a default choice in every dropdown list, not only branches, to let the corresponding value unchanged Signed-off-by: Liz Rea <wizzyrea@gmail.com> Patch works as advertised
I second Liz's request for clarification on the necessity of this change.
(In reply to comment #10) > Sophie, > > Doesn't the checkbox serve the same purpose? Not at all !!! the checkbox are here to force *emptying* the subfield. The doc says: "Checking the box right next the subfield label will disable the entry and delete the values of that subfield on all selected items" The "empty value" in other lists means "don't change anything to the existing value" > Is there an additional use case > that makes this new patch necessary? Switching back to signed-off. If you agree with my explanatin, you can mark as "passed QA" because it's a small patch, nothing to say. Then i'll push it. (not pushing it immediatly just to double check everything is OK with the behaviour)
Paul, Thanks for the clarification, that clears up what I needed to pass this patch through QA (it's a simple patch with little chance of any regressions anywhere).
This patch will be in 3.6.5 (no string changes).