April 2023 - Koha-bugs - lists.koha-community.org

[Bug 27546] New: Add option to search within results on the staff client
by bugzilla-daemon＠bugs.koha-community.org 15 May '23

15 May '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=27546 Bug ID: 27546 Summary: Add option to search within results on the staff client Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Searching Assignee: koha-bugs(a)lists.koha-community.org Reporter: nick(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org This enhancement will add a new box above the search results allowing one to search within the previous search results -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 48

[Bug 33097] New: Is message for staff or OPAC on circulation.pl?
by bugzilla-daemon＠bugs.koha-community.org 15 May '23

15 May '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33097 Bug ID: 33097 Summary: Is message for staff or OPAC on circulation.pl? Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Patrons Assignee: koha-bugs(a)lists.koha-community.org Reporter: cbrannon(a)cdalibrary.org QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com When looking at patron messages (not notices) on circulation.pl, it is impossible to tell if a message was posted to staff or to the OPAC. They display differently, with one red and the other not. But that doesn't tell the staff member which is which. We should have some kind of indicator to differentiate the two types. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 2

[Bug 31245] New: Job detail view for batch mod explode if job not started
by bugzilla-daemon＠bugs.koha-community.org 15 May '23

15 May '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=31245 Bug ID: 31245 Summary: Job detail view for batch mod explode if job not started Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: ASSIGNED Severity: normal Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: jonathan.druart+koha(a)gmail.com Reporter: jonathan.druart+koha(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org If the job has failed to start (status=new), the job detail view is exploding with Can't use an undefined value as an ARRAY reference at /kohadevbox/koha/Koha/BackgroundJob/BatchUpdateItem.pm line 175 Koha::BackgroundJob::BatchUpdateItem::additional_report('Koha::BackgroundJob::BatchUpdateItem=HASH(0x5592c6c6ced8)') called at /kohadevbox/koha/Koha/BackgroundJob.pm line 339 Koha::BackgroundJob::additional_report('Koha::BackgroundJob=HASH(0x5592c6df3268)') called at /kohadevbox/koha/admin/background_jobs.pl line 55 -- You are receiving this mail because: You are watching all bug changes.

1 33

[Bug 33191] New: AutoEmailPrimaryAddress options don't match labels in memberentry
by bugzilla-daemon＠bugs.koha-community.org 15 May '23

15 May '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33191 Bug ID: 33191 Summary: AutoEmailPrimaryAddress options don't match labels in memberentry Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Staff interface Assignee: koha-bugs(a)lists.koha-community.org Reporter: martin.renvoize(a)ptfs-europe.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com This preference is confusing as the options it contains don't all match the labels for the corresponding fields in the member entry forms. * 'work'.. this corresponds to 'Secondary email' * 'home'.. this corresponds to 'Primary email' * 'alternate'.. ? We should either hint what these fields 'mean' on the form or update the systempreference options to match the existing form field label? -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 31

[Bug 32546] New: Move ILL system preferences to their own tab in administration
by bugzilla-daemon＠bugs.koha-community.org 15 May '23

15 May '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32546 Bug ID: 32546 Summary: Move ILL system preferences to their own tab in administration Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: ILL Assignee: koha-bugs(a)lists.koha-community.org Reporter: katrin.fischer(a)bsz-bw.de At the moment the ILL related system preference appear on the Circulation tab, which is already very long. As ILL is a module, it should have its own tab. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 16

[Bug 32021] New: Pages 'appear in position' field is not useful
by bugzilla-daemon＠bugs.koha-community.org 15 May '23

15 May '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32021 Bug ID: 32021 Summary: Pages 'appear in position' field is not useful Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Tools Assignee: koha-bugs(a)lists.koha-community.org Reporter: caroline.cyr-la-rose(a)inlibro.com QA Contact: testopia(a)bugs.koha-community.org When creating a new page with the additional content page, there is a possibility of adding an 'appears in position' to the page. I think this is a leftover from the news/html customizations tool where you could have many entries in the same location and they would be ordered by 'appears in position'. However, I don't think it is useful in the case of pages and should probably be removed. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 19

[Bug 33354] New: Error 400 Bad Request when submitting form in ERM
by bugzilla-daemon＠bugs.koha-community.org 15 May '23

15 May '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33354 Bug ID: 33354 Summary: Error 400 Bad Request when submitting form in ERM Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: ERM Assignee: jonathan.druart+koha(a)gmail.com Reporter: pedro.amorim(a)ptfs-europe.com CC: jonathan.druart+koha(a)gmail.com, jonathan.field(a)ptfs-europe.com, martin.renvoize(a)ptfs-europe.com, pedro.amorim(a)ptfs-europe.com Depends on: 32030 To reproduce: * Add new agreement * Fill in the preliminary mandatory fields (name and status) * Click "add new user" * Select a user role, do not pick a user * Submit You will get a 400 Bad Request error. This is likely also happening in Licenses. --- This would likely be fixed by making the user field mandatory Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32030 [Bug 32030] Electronic resource management (ERM) -- You are receiving this mail because: You are watching all bug changes.

1 18

[Bug 33402] New: ERM Cypress tests needs to be moved to their own directory
by bugzilla-daemon＠bugs.koha-community.org 15 May '23

15 May '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33402 Bug ID: 33402 Summary: ERM Cypress tests needs to be moved to their own directory Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: ASSIGNED Severity: normal Priority: P5 - low Component: Test Suite Assignee: jonathan.druart+koha(a)gmail.com Reporter: jonathan.druart+koha(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org We need to move the existing Cypress tests (that are ERM only, t/cypress/integration/*.ts ) to their own subdirectory, eg t/cypress/integration/ERM -- You are receiving this mail because: You are watching all bug changes.

1 24

[Bug 33403] New: Letters.t: Foreign key exception if you do not have a numberpattern with id=1
by bugzilla-daemon＠bugs.koha-community.org 15 May '23

15 May '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33403 Bug ID: 33403 Summary: Letters.t: Foreign key exception if you do not have a numberpattern with id=1 Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Test Suite Assignee: chris(a)bigballofwax.co.nz Reporter: m.de.rooy(a)rijksmuseum.nl QA Contact: testopia(a)bugs.koha-community.org Letters.t $dbh->do(q|UPDATE subscription_numberpatterns SET numberingmethod='No. {X}' WHERE id=1|); t/db_dependent/Letters.t .. 51/85 DBIx::Class::Storage::DBI::_dbh_execute(): DBI Exception: DBD::mysql::st execute failed: Cannot add or update a child row: a foreign key constraint fails (`koha_myclone`.`subscription`, CONSTRAINT `subscription_ibfk_2` FOREIGN KEY (`numberpattern`) REFERENCES `subscription_numberpatterns` (`id`) ON DELETE SET NULL ON UPDATE CASCADE) at /usr/share/koha/Koha/Object.pm line 170 Hmm. You should have a record with id=1 in your table. This is bad. -- You are receiving this mail because: You are watching all bug changes.

1 10

[Bug 33567] New: Remove fallback for Reference_NFL_statuses in C4/XSLT module
by bugzilla-daemon＠bugs.koha-community.org 15 May '23

15 May '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33567 Bug ID: 33567 Summary: Remove fallback for Reference_NFL_statuses in C4/XSLT module Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: koha-bugs(a)lists.koha-community.org Reporter: m.de.rooy(a)rijksmuseum.nl QA Contact: testopia(a)bugs.koha-community.org C4/XSLT contains this line: my $ref_status = C4::Context->preference('Reference_NFL_Statuses') || '1|2'; This is a kind of undocumented fallback (that I introduced myself). We should either add this to the pref text or just do what is kind of intuitively expected: if the pref is empty, move all items to Not available. Note that the installer creates the pref by default with 1|2. So this might be a quite theoretical change for most. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 16