Summary: | Can't edit bibliographic records anymore (empty form) | ||
---|---|---|---|
Product: | Koha | Reporter: | zefanjas <koha> |
Component: | Cataloging | Assignee: | Jonathan Druart <jonathan.druart> |
Status: | Pushed to stable --- | QA Contact: | Marcel de Rooy <m.de.rooy> |
Severity: | major | ||
Priority: | P1 - high | CC: | bibliothek, david, emily.lamancusa, jonathan.druart, lucas, m.de.rooy, phil |
Version: | unspecified | Keywords: | RM_priority |
Hardware: | All | ||
OS: | All | ||
Change sponsored?: | --- | Patch complexity: | Trivial patch |
Documentation contact: | Documentation submission: | ||
Text to go in the release notes: | Version(s) released in: |
24.11.00,24.05.04
|
|
Circulation function: | |||
Bug Depends on: | |||
Bug Blocks: | 36192, 37499 | ||
Attachments: |
Bug 37429: Set default value for global variables
Bug 37429: Set default value for global variables Bug 37429: Set default value for global variables |
Description
zefanjas
2024-07-23 09:19:38 UTC
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 |