It happens that librarians, by mistake, open a biblio editor putting in the URL, by hand, the biblionumber prefixed with a blank (e.g. .../addbiblio.pl?biblionumber= 123 -- mind the space before 123). In such a case the editor opens with the right biblio record (i.e. 123) but, after saving the record, the content of the biblionumber MARC field (999 $c for a standard MARC 21 installation) results modified and contains additional initial blanks. Moreover, while using ES and making a search for the record (with title, author etc.) we get two records on the result list (instead of one). This is because in the addbiblio.pl script $biblionumber is taken (and continuously used) directly from CGI parameter, without any validation and/or correction.
Created attachment 166224 [details] [review] Bug 36794: Bug 36794 - Illegitimate modification of biblionumber subfield content (999 $c) It happens that librarians, by mistake, open a biblio editor putting in the URL, by hand, the biblionumber prefixed with a blank (e.g. .../addbiblio.pl?biblionumber= 123 -- mind the space before 123). In such a case the editor opens with the right biblio record (i.e. 123) but, after saving the record, the content of the biblionumber MARC field (999 $c for a standard MARC 21 installation) results modified and contains additional initial blanks. Moreover, while using ES and making a search for the record (with title, author etc.) we get two records on the result list (instead of one). This is because in the addbiblio.pl script $biblionumber is taken (and continuously used) directly from CGI parameter, without any validation and/or correction. Test plan: ========== 0. Have a test installation with ES. 1. Open a biblio record in the editor with an added space before biblionumber value, e.g.: http://ktd:8081/cgi-bin/koha/cataloguing/addbiblio.pl?biblionumber= 123 Save the record. 2. From the Normal view choose Save -> MARCXML. Open the saved file in your favourite editor. You should see, at the end, something like: <datafield tag="999" ind1=" " ind2=" "> <subfield code="c"> 123</subfield> (mind the space before 123). This is not right. 3. Make a search with the title or author's name from the record (e.g. Henning Mankell for the record 123 from the default ktd data set). You should get two records instead of one (while using ES). 4. Apply the patch, restart_all. Repeat p. 1 and 2 with a different biblionumber. Notice the unchanged (i.e. without spaces) value of 999 $c subfield in the exported record and only one record as a result of a search. Sponsored-by: Ignatianum University in Cracow
Created attachment 166235 [details] [review] Bug 36794: Bug 36794 - Illegitimate modification of biblionumber subfield content (999 $c) It happens that librarians, by mistake, open a biblio editor putting in the URL, by hand, the biblionumber prefixed with a blank (e.g. .../addbiblio.pl?biblionumber= 123 -- mind the space before 123). In such a case the editor opens with the right biblio record (i.e. 123) but, after saving the record, the content of the biblionumber MARC field (999 $c for a standard MARC 21 installation) results modified and contains additional initial blanks. Moreover, while using ES and making a search for the record (with title, author etc.) we get two records on the result list (instead of one). This is because in the addbiblio.pl script $biblionumber is taken (and continuously used) directly from CGI parameter, without any validation and/or correction. Test plan: ========== 0. Have a test installation with ES. 1. Open a biblio record in the editor with an added space before biblionumber value, e.g.: http://ktd:8081/cgi-bin/koha/cataloguing/addbiblio.pl?biblionumber= 123 Save the record. 2. From the Normal view choose Save -> MARCXML. Open the saved file in your favourite editor. You should see, at the end, something like: <datafield tag="999" ind1=" " ind2=" "> <subfield code="c"> 123</subfield> (mind the space before 123). This is not right. 3. Make a search with the title or author's name from the record (e.g. Henning Mankell for the record 123 from the default ktd data set). You should get two records instead of one (while using ES). 4. Apply the patch, restart_all. Repeat p. 1 and 2 with a different biblionumber. Notice the unchanged (i.e. without spaces) value of 999 $c subfield in the exported record and only one record as a result of a search. Sponsored-by: Ignatianum University in Cracow Signed-off-by: Roman Dolny <roman.dolny@jezuici.pl>
Created attachment 166236 [details] [review] Bug 36794: Illegitimate modification of biblionumber subfield content (999 $c) It happens that librarians, by mistake, open a biblio editor putting in the URL, by hand, the biblionumber prefixed with a blank (e.g. .../addbiblio.pl?biblionumber= 123 -- mind the space before 123). In such a case the editor opens with the right biblio record (i.e. 123) but, after saving the record, the content of the biblionumber MARC field (999 $c for a standard MARC 21 installation) results modified and contains additional initial blanks. Moreover, while using ES and making a search for the record (with title, author etc.) we get two records on the result list (instead of one). This is because in the addbiblio.pl script $biblionumber is taken (and continuously used) directly from CGI parameter, without any validation and/or correction. Test plan: ========== 0. Have a test installation with ES. 1. Open a biblio record in the editor with an added space before biblionumber value, e.g.: http://ktd:8081/cgi-bin/koha/cataloguing/addbiblio.pl?biblionumber= 123 Save the record. 2. From the Normal view choose Save -> MARCXML. Open the saved file in your favourite editor. You should see, at the end, something like: <datafield tag="999" ind1=" " ind2=" "> <subfield code="c"> 123</subfield> (mind the space before 123). This is not right. 3. Make a search with the title or author's name from the record (e.g. Henning Mankell for the record 123 from the default ktd data set). You should get two records instead of one (while using ES). 4. Apply the patch, restart_all. Repeat p. 1 and 2 with a different biblionumber. Notice the unchanged (i.e. without spaces) value of 999 $c subfield in the exported record and only one record as a result of a search. Sponsored-by: Ignatianum University in Cracow Signed-off-by: Roman Dolny <roman.dolny@jezuici.pl>
Created attachment 166587 [details] [review] Bug 36794: Illegitimate modification of biblionumber subfield content (999 $c) It happens that librarians, by mistake, open a biblio editor putting in the URL, by hand, the biblionumber prefixed with a blank (e.g. .../addbiblio.pl?biblionumber= 123 -- mind the space before 123). In such a case the editor opens with the right biblio record (i.e. 123) but, after saving the record, the content of the biblionumber MARC field (999 $c for a standard MARC 21 installation) results modified and contains additional initial blanks. Moreover, while using ES and making a search for the record (with title, author etc.) we get two records on the result list (instead of one). This is because in the addbiblio.pl script $biblionumber is taken (and continuously used) directly from CGI parameter, without any validation and/or correction. Test plan: ========== 0. Have a test installation with ES. 1. Open a biblio record in the editor with an added space before biblionumber value, e.g.: http://ktd:8081/cgi-bin/koha/cataloguing/addbiblio.pl?biblionumber= 123 Save the record. 2. From the Normal view choose Save -> MARCXML. Open the saved file in your favourite editor. You should see, at the end, something like: <datafield tag="999" ind1=" " ind2=" "> <subfield code="c"> 123</subfield> (mind the space before 123). This is not right. 3. Make a search with the title or author's name from the record (e.g. Henning Mankell for the record 123 from the default ktd data set). You should get two records instead of one (while using ES). 4. Apply the patch, restart_all. Repeat p. 1 and 2 with a different biblionumber. Notice the unchanged (i.e. without spaces) value of 999 $c subfield in the exported record and only one record as a result of a search. WNC amended patch - rebased, added conditional in case no bib, moved comments to their own lines Sponsored-by: Ignatianum University in Cracow Signed-off-by: Roman Dolny <roman.dolny@jezuici.pl> Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
This a bug 36799 are a little odd, but biblionumber and authid should always be numeric, it fixes issues if a library does a bad copy and paste, passing QA
Please rebase - I didn't want to mess it up :)
Created attachment 166619 [details] [review] Bug 36794: Illegitimate modification of biblionumber subfield content (999 $c) It happens that librarians, by mistake, open a biblio editor putting in the URL, by hand, the biblionumber prefixed with a blank (e.g. .../addbiblio.pl?biblionumber= 123 -- mind the space before 123). In such a case the editor opens with the right biblio record (i.e. 123) but, after saving the record, the content of the biblionumber MARC field (999 $c for a standard MARC 21 installation) results modified and contains additional initial blanks. Moreover, while using ES and making a search for the record (with title, author etc.) we get two records on the result list (instead of one). This is because in the addbiblio.pl script $biblionumber is taken (and continuously used) directly from CGI parameter, without any validation and/or correction. Test plan: ========== 0. Have a test installation with ES. 1. Open a biblio record in the editor with an added space before biblionumber value, e.g.: http://ktd:8081/cgi-bin/koha/cataloguing/addbiblio.pl?biblionumber= 123 Save the record. 2. From the Normal view choose Save -> MARCXML. Open the saved file in your favourite editor. You should see, at the end, something like: <datafield tag="999" ind1=" " ind2=" "> <subfield code="c"> 123</subfield> (mind the space before 123). This is not right. 3. Make a search with the title or author's name from the record (e.g. Henning Mankell for the record 123 from the default ktd data set). You should get two records instead of one (while using ES). 4. Apply the patch, restart_all. Repeat p. 1 and 2 with a different biblionumber. Notice the unchanged (i.e. without spaces) value of 999 $c subfield in the exported record and only one record as a result of a search. WNC amended patch - rebased, added conditional in case no bib, moved comments to their own lines Sponsored-by: Ignatianum University in Cracow Signed-off-by: Roman Dolny <roman.dolny@jezuici.pl> Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
(In reply to Katrin Fischer from comment #6) > Please rebase - I didn't want to mess it up :) Done--should apply smoothly now. Thank you!
Pushed for 24.05! Well done everyone, thank you!
Pushed to 23.11.x for 23.11.06
Backported to 23.05.x for upcoming 23.05.12
When creating a fresh record, I'm seeing this in the logs: [2024/08/26 17:52:31] [WARN] Use of uninitialized value in substitution (s///) at /kohadevbox/koha/Koha/UI/Form/Builder/Biblio.pm line 53.
(In reply to Tomás Cohen Arazi from comment #12) > When creating a fresh record, I'm seeing this in the logs: > > [2024/08/26 17:52:31] [WARN] Use of uninitialized value in substitution > (s///) at /kohadevbox/koha/Koha/UI/Form/Builder/Biblio.pm line 53. Thanks Tomás for catching this. I have submitted a new bug 37867.
additional_work_needed resolved by bug 37870.