December 2022 - Koha-bugs - lists.koha-community.org

[Bug 30483] New: Should issues.borrowernumber and issues.itemnumber be NOT NULL ?
by bugzilla-daemon＠bugs.koha-community.org 21 Mar '23

21 Mar '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=30483 Bug ID: 30483 Summary: Should issues.borrowernumber and issues.itemnumber be NOT NULL ? Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Database Assignee: koha-bugs(a)lists.koha-community.org Reporter: m.de.rooy(a)rijksmuseum.nl QA Contact: testopia(a)bugs.koha-community.org Sync problem between structure and dbrevs. For old prod databases only (that passed the 3.05 dbrevs) Note that I did not expect such a difference in a vital table like issues ! update $DBversion = "3.05.00.009"; $dbh->do("ALTER TABLE issues MODIFY COLUMN borrowernumber int(11) NOT NULL"); $dbh->do("ALTER TABLE issues MODIFY COLUMN itemnumber int(11) NOT NULL"); Current structure allows them to be NULL. I wonder if that is correct. An issue should have a borrower and an item, right? -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 27

[Bug 30172] New: BackGround jobs failing due to race condition
by bugzilla-daemon＠bugs.koha-community.org 21 Mar '23

21 Mar '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=30172 Bug ID: 30172 Summary: BackGround jobs failing due to race condition Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: major Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: koha-bugs(a)lists.koha-community.org Reporter: nick(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org We are receiving reports from production of background jobs that show as 'new' in the database that are not being processed. There are no errors or exceptions relating to enqueueing from the broker We do see in the worker-output.log: Can't call method "process" on an undefined value at /usr/share/koha/bin/background_jobs_worker.pl line 80. In Koha/BackGroundJob.pm: 94 sub enqueue { ... 104 $self->_result->result_source->schema->txn_do( 105 sub { 106 $self->set( 107 { 108 status => 'new', ... 114 } 115 )->store; ... 121 try { 122 my $conn = $self->connect; ... 128 $conn->send_with_receipt( { destination => sprintf("/queue/%s-%s", $namespace, $job_type), body => $json_args } ) 129 or Koha::Exceptions::Exception->throw('Job has not been enqueued'); 130 } catch { ... 138 ); ^^End of transaction What appears to be happening is that: 1 - The transaction is begun 2 - Job info is stored internally, but not committed 3 - the job is being sent to Rabbit 4 - Rabbit attempts to process the job, and fails as it cannot find the data in the DB 3 - The transaction completes We are left with jobs sitting at 'new' with no errors and they are never processed -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 72

[Bug 32077] New: 'Close and Export as PDF' doesn't work on basketgroups page
by bugzilla-daemon＠bugs.koha-community.org 20 Mar '23

20 Mar '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32077 Bug ID: 32077 Summary: 'Close and Export as PDF' doesn't work on basketgroups page Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: major Priority: P5 - low Component: Acquisitions Assignee: koha-bugs(a)lists.koha-community.org Reporter: martin.renvoize(a)ptfs-europe.com QA Contact: testopia(a)bugs.koha-community.org If you attempt to 'Close and Export as PDF' a basketgroup from the open basketgroups tab of a vendor basketgroup page the action fails and an error is shown in the console. Uncaught ReferenceError: closeandprint is not defined onclick http://mrdev-zebra-staff.koha-ptfs.co.uk/cgi-bin/koha/acqui/basketgroup.pl?… basketgroup.pl:1:1 -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 1

[Bug 31056] New: Unable to 'Close and export as PDF' a basket group
by bugzilla-daemon＠bugs.koha-community.org 20 Mar '23

20 Mar '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=31056 Bug ID: 31056 Summary: Unable to 'Close and export as PDF' a basket group Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Acquisitions Assignee: koha-bugs(a)lists.koha-community.org Reporter: caroline.cyr-la-rose(a)inlibro.com QA Contact: testopia(a)bugs.koha-community.org The button to 'Close and export as PDF' in the basket groups page seems to be broken. To test: 0) Make sure to have budgets, funds, and vendors set up in the acquisitions module 1) Go to Acquisitions 2) Search for a vendor 3) Create a new basket 4) Add materials to the basket 5) Close the basket (do NOT create a basket group at this time) 6) Click on the Basket groups tab on the left 7) Create a new basket group and add the basket (do NOT check the 'close basket group' box) 8) From the open basket groups list, click 'Close and export as PDF' --> Nothing happens In order to export as PDF, you have to edit the basket group, check the 'Close basket group' box, save and then export as PDF. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 19

[Bug 26413] New: Reading history management from staff client.
by bugzilla-daemon＠bugs.koha-community.org 20 Mar '23

20 Mar '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26413 Bug ID: 26413 Summary: Reading history management from staff client. Change sponsored?: --- Product: Koha Version: 19.11 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Patrons Assignee: koha-bugs(a)lists.koha-community.org Reporter: estherm(a)sodaspringsid.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com Currently reading/circulation history tracking is controlled by settings in the Patron Categories with the Default Privacy options. Setting the Default Privacy setting to 'Default' means that keeping a reading history becomes an opt-out where a patron has to turn it off in their patron account from the OPAC. Setting the Default Privacy setting to 'Never' means that keeping a reading history becomes an opt-in where a patron has to turn it on through their patron account. This becomes a problem either way when working with patrons who are unable or unwilling to login to their patron account to select their preferred option. It would be nice to have an option in the patron account details that allows a staff member to flip the switch for the patron. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 3

[Bug 30925] New: Cannot create public lists in OPAC or staff ?
by bugzilla-daemon＠bugs.koha-community.org 20 Mar '23

20 Mar '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=30925 Bug ID: 30925 Summary: Cannot create public lists in OPAC or staff ? Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Lists Assignee: koha-bugs(a)lists.koha-community.org Reporter: m.de.rooy(a)rijksmuseum.nl QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl Suspecting 26346 .. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 28

[Bug 31880] New: "Go to field" link in MARC validation goes nowhere if field not in the same tab
by bugzilla-daemon＠bugs.koha-community.org 20 Mar '23

20 Mar '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=31880 Bug ID: 31880 Summary: "Go to field" link in MARC validation goes nowhere if field not in the same tab Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Cataloging Assignee: koha-bugs(a)lists.koha-community.org Reporter: caroline.cyr-la-rose(a)inlibro.com QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl I'm having trouble with the "Go to field" link when you don't fill in a mandatory field when cataloging. Normally, it takes you to the field, but now it doesn't seem to do anything if the field is not in the current tab... To test: (Note: I did this with the default framework in MARC21, when I refer to fields, they are MARC21 fields and they are mandatory by default in the default framework) 1. Go to Cataloging > New record 2. Click "Save" without filling anything out --> You should get a bunch of warnings about mandatory fields that are not filled 3. Click "Go to field" next to the 245$a error --> Nothing happens 4. Click "Go to field" next to the 040$c error --> You are taken to 040$c 5. Click on tab 2 6. Click Save again (not sure it's necessary) 7. Redo step 3 --> You are taken to 245$a 8. Redo step 4 --> Nothing happens -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 4

[Bug 32523] New: Shortcuts / Links to missing fields in MARC-Editor don't work as expected
by bugzilla-daemon＠bugs.koha-community.org 20 Mar '23

20 Mar '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32523 Bug ID: 32523 Summary: Shortcuts / Links to missing fields in MARC-Editor don't work as expected Change sponsored?: --- Product: Koha Version: 22.11 Hardware: All OS: Linux Status: NEW Severity: minor Priority: P5 - low Component: Staff interface Assignee: koha-bugs(a)lists.koha-community.org Reporter: bibliothek(a)th-wildau.de QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com The links / shortcuts to missing mandatory fields in the biblio marc editor won't work after redesign (or update from 22.05 to 22.11). Clicking on a "Go to field"-button will not focus that specific field. Test plan: * go to /cgi-bin/koha/cataloguing/addbiblio.pl?frameworkcode= * click Save * Error dialog appears, informing about missing input in mandatory fields. * Click on tab 0 (section 0) to make sure only marc 0XX fields are visible. * In the error dialog click on a "Go to field" which points f.e. to section 9 * The selected / active tab will switch to section 9 and will not focus on the selected field I already have a clue how to solve that issue and try to upload a patch -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 35

[Bug 31924] New: AutoLinkBiblios broken by patch from Bug 30280
by bugzilla-daemon＠bugs.koha-community.org 18 Mar '23

18 Mar '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=31924 Bug ID: 31924 Summary: AutoLinkBiblios broken by patch from Bug 30280 Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Keywords: regression Severity: major Priority: P5 - low Component: MARC Authority data support Assignee: koha-bugs(a)lists.koha-community.org Reporter: phil(a)chetcolibrary.org QA Contact: testopia(a)bugs.koha-community.org CC: frank.hansen(a)ub.lu.se Depends on: 30280 With AutoLinkBiblios set to "Do", when you save a biblio after adding an authority-controlled field, it should be linked to the matching authority. With the patch from bug 30280, it no longer is. Steps to reproduce: 1. Set AutoLinkBiblios to "Do". 2. Edit any bib record which does not already have a subject heading for "Perl (Computer language)". 3. Add a new 650 tag, with subfield a containing Perl (Computer language) and save the record 4. Re-edit the record, note that there is no authority record number in subfield 9 of the added 650. 5. git checkout 7a829606a46f5d3c2056ce9da5134ce293d584ad and verify that the steps above resulted in an authority record number in subfield 9 on the parent revision Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=30280 [Bug 30280] Support authority records with common subject headings from different thesaurus -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 8

[Bug 25856] New: Suspended holds should be styled differently on request.pl
by bugzilla-daemon＠bugs.koha-community.org 17 Mar '23

17 Mar '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25856 Bug ID: 25856 Summary: Suspended holds should be styled differently on request.pl Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: andrew(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com When looking at the list of holds on request.pl, it's not terribly obvious when a hold is suspended. It'd be great to make that line appear in a different color or something else immediately obvious. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 16