While cataloging new books the edit / add biblio form is sometimes empty. This happens also when I want to edit an existing biblio or import one via Z.39.50. Sometime I can add 5-10 new items before it happens, sometimes it happens after every new record. The only "fix" right now for me is to do a `service koha-common restart`. The log files don't show any error. To reproduce the issue: 1. Open an existing biblio (detail.pl) 2. Click "Edit record" 3. Change the framework (no need to change any details) 4. Change the framework back to the original one (no need to save anything) 5. Go back to the biblio overview page (detail.pl) 6. Click "Edit record" again → mask / form is empty
This behavior is caused by $changed_framework with a value = 1 even when calling addbiblio.pl without an param op: our($tagslib,$authorised_values_sth,$is_a_modif,$usedTagsLib,$mandatory_z3950,$op,$changed_framework);
git bisect points to commit 3f2a8ecf3c9f3421260657bfc779029e6ae75f2c Bug 34478: Regression - fix change framework https://git.koha-community.org/Koha-community/Koha/commit/3f2a8ecf3c9f3421260657bfc779029e6ae75f2c
Interestingly, I cannot reproduce this if I disable and then stop Plack (followed by a restart of memcached and apache2). The following quick and dirty patch seems to fix things (even when Plack and memcached are enabled): diff --git a/cataloguing/addbiblio.pl b/cataloguing/addbiblio.pl index 99c20580b5..754aaf175a 100755 --- a/cataloguing/addbiblio.pl +++ b/cataloguing/addbiblio.pl @@ -518,6 +518,7 @@ my $fa_duedatespec = $input->param('duedatespec'); my $userflags = 'edit_catalogue'; +$changed_framework = 0; if ( $op eq 'cud-change-framework' ) { $op = $input->param('original_op'); $changed_framework = 1; Not sure about the quality of the above solution, though?
(In reply to Andreas Roussos from comment #3) > Interestingly, I cannot reproduce this if I disable and then > stop Plack (followed by a restart of memcached and apache2). > > The following quick and dirty patch seems to fix things > (even when Plack and memcached are enabled): > > diff --git a/cataloguing/addbiblio.pl b/cataloguing/addbiblio.pl > index 99c20580b5..754aaf175a 100755 > --- a/cataloguing/addbiblio.pl > +++ b/cataloguing/addbiblio.pl > @@ -518,6 +518,7 @@ my $fa_duedatespec = $input->param('duedatespec'); > > my $userflags = 'edit_catalogue'; > > +$changed_framework = 0; > if ( $op eq 'cud-change-framework' ) { > $op = $input->param('original_op'); > $changed_framework = 1; > > Not sure about the quality of the above solution, though? The bigger issue is that $changed_framework (as well as others) shouldn't really be global variables in the first place. I don't quite understand Perl's scoping rules well enough to be able to say how big of a refactor it would be to fix that, though. In the meantime, I'd say your patch is worth doing to fix the major bug. We already do that with $is_a_modif, and it's a simple change. I'll file a follow-up bug to address the underlying issue.
Created attachment 170346 [details] [review] Bug 37429: Set default value for global variables The global variables needs to be assigned with a default value, or the value from the previous request will be used. Global variables are persistent from one request to another, in memory. This patch: * groups default value for global variables together * removes $authorised_values_sth from this list (it is not a global var) * set $changed_framework to 0 (which fix the issue) Test plan: 1. Open an existing biblio (detail.pl) 2. Click "Edit record" 3. Change the framework (no need to change any details) 4. Change the framework back to the original one (no need to save anything) 5. Go back to the biblio overview page (detail.pl) => The form is populated
Created attachment 170356 [details] [review] Bug 37429: Set default value for global variables The global variables needs to be assigned with a default value, or the value from the previous request will be used. Global variables are persistent from one request to another, in memory. This patch: * groups default value for global variables together * removes $authorised_values_sth from this list (it is not a global var) * set $changed_framework to 0 (which fix the issue) Test plan: 1. Open an existing biblio (detail.pl) 2. Click "Edit record" 3. Change the framework (no need to change any details) 4. Change the framework back to the original one (no need to save anything) 5. Go back to the biblio overview page (detail.pl) => The form is populated Signed-off-by: Paul Derscheid <paul.derscheid@lmscloud.de>
Looking here
Created attachment 170424 [details] [review] Bug 37429: Set default value for global variables The global variables needs to be assigned with a default value, or the value from the previous request will be used. Global variables are persistent from one request to another, in memory. This patch: * groups default value for global variables together * removes $authorised_values_sth from this list (it is not a global var) * set $changed_framework to 0 (which fix the issue) Test plan: 1. Open an existing biblio (detail.pl) 2. Click "Edit record" 3. Change the framework (no need to change any details) 4. Change the framework back to the original one (no need to save anything) 5. Go back to the biblio overview page (detail.pl) => The form is populated Signed-off-by: Paul Derscheid <paul.derscheid@lmscloud.de> Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Pushed for 24.11! Well done everyone, thank you!
Backported to 24.05.x for upcoming 24.05.04
Looks like this is mainly for $op. Since in 23.11.x $op is not global, is this needed. If yes please provide rebased patches.