March 2017 - Koha-bugs - lists.koha-community.org

[Bug 18138] New: Use MARC modification template when adding/ updating bibliographic records
by bugzilla-daemon＠bugs.koha-community.org 29 Feb '24

29 Feb '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=18138 Bug ID: 18138 Summary: Use MARC modification template when adding/updating bibliographic records Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Cataloging Assignee: gmcharlt(a)gmail.com Reporter: stefan.berndtsson(a)ub.gu.se QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl When importing records, MARC modification templates can be used to silently remove unwanted tags among other thing. The same thing could be useful when adding/updating bibliographic records from within Koha. I therefor propose an addition of a SysPref to set a default template to use in AddBiblio and ModBiblio before TransformMarcToKoha is called. -- You are receiving this mail because: You are watching all bug changes.

1 117

[Bug 17975] New: TT syntax for notices - Prove that HOLD_SLIP is compatible
by bugzilla-daemon＠bugs.koha-community.org 16 Feb '24

16 Feb '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17975 Bug ID: 17975 Summary: TT syntax for notices - Prove that HOLD_SLIP is compatible Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: ASSIGNED Severity: enhancement Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: jonathan.druart(a)bugs.koha-community.org Reporter: jonathan.druart(a)bugs.koha-community.org QA Contact: testopia(a)bugs.koha-community.org -- You are receiving this mail because: You are watching all bug changes.

1 21

[Bug 17967] New: TT syntax for notices - Prove that ODUE is compatible
by bugzilla-daemon＠bugs.koha-community.org 15 Feb '24

15 Feb '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17967 Bug ID: 17967 Summary: TT syntax for notices - Prove that ODUE is compatible Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: ASSIGNED Severity: enhancement Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: jonathan.druart(a)bugs.koha-community.org Reporter: jonathan.druart(a)bugs.koha-community.org QA Contact: testopia(a)bugs.koha-community.org -- You are receiving this mail because: You are watching all bug changes.

1 18

[Bug 17427] New: Replace CGI::Session with Data::Session
by bugzilla-daemon＠bugs.koha-community.org 15 Feb '24

15 Feb '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17427 Bug ID: 17427 Summary: Replace CGI::Session with Data::Session Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: gmcharlt(a)gmail.com Reporter: jonathan.druart(a)bugs.koha-community.org QA Contact: testopia(a)bugs.koha-community.org CGI::Session is not maintained for ages and seems quite buggy. It would be the culprit of random logout problems. Another issue is the following crazy code in CGI::Session::Driver::DBI sub DESTROY { my $self = shift; unless ( defined $self->{Handle} && $self->{Handle} -> ping ) { $self->set_error(__PACKAGE__ . '::DESTROY(). Database handle has gone away'); return; } unless ( $self->{Handle}->{AutoCommit} ) { $self->{Handle}->commit; } if ( $self->{_disconnect} ) { $self->{Handle}->disconnect; } } If AutoCommit is off, it will commit anyway... It causes some tests to fail (api) if SessionStorage is set to MySQL -- You are receiving this mail because: You are watching all bug changes.

1 131

[Bug 17120] New: Specify number of rows per page in report and initial run
by bugzilla-daemon＠bugs.koha-community.org 14 Feb '24

14 Feb '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17120 Bug ID: 17120 Summary: Specify number of rows per page in report and initial run Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Reports Assignee: gmcharlt(a)gmail.com Reporter: cbrannon(a)cdalibrary.org QA Contact: testopia(a)bugs.koha-community.org I think we could enhance reports so that the &limit= parameter could be initially set with the report settings and stored in a field in the table. I also think we could have the drop down available on the parameters page when running the report the first time. If you have a report you know that would run well and could be completely shown with more rows, why not have the option to initially set it differently than the default? The LIMIT command in SQL is okay and works for actually limiting the total number of results, but does weird things if you specify a number larger than 20. The results still span multiple pages, plus it doesn't give you options while running like this would. -- You are receiving this mail because: You are watching all bug changes.

1 9

[Bug 16117] New: Feature request: Log borrower cardnumbers and item barcodes which are not valid
by bugzilla-daemon＠bugs.koha-community.org 12 Feb '24

12 Feb '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=16117 Bug ID: 16117 Summary: Feature request: Log borrower cardnumbers and item barcodes which are not valid Change sponsored?: --- Product: Koha Version: 3.18 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: barton(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com On any circ screen where a barcode could be scanned (circ.pl, checkin.pl, checkout and return boxes), we should have the option of logging failed barcode scans, for the purpose of trouble-shooting. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 44

[Bug 17337] New: waitingreserves.pl should trigger transfers as well as holds
by bugzilla-daemon＠bugs.koha-community.org 10 Feb '24

10 Feb '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17337 Bug ID: 17337 Summary: waitingreserves.pl should trigger transfers as well as holds Change sponsored?: --- Product: Koha Version: 3.22 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Hold requests 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 Bug 17010 addresses triggering the next hold when a hold is cancelled, but transfers should also be triggered. Currently in 3.22.8 nothing happens. It is unclear if 17010 addresses transfers as well. Also, in 3.18 local holds were spotty when holds were triggered. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 5

[Bug 17755] New: Move C4::Members::AttributeTypes to Koha::* namespace
by bugzilla-daemon＠bugs.koha-community.org 31 Jan '24

31 Jan '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17755 Bug ID: 17755 Summary: Move C4::Members::AttributeTypes to Koha::* namespace Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: gmcharlt(a)gmail.com Reporter: tomascohen(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org -- You are receiving this mail because: You are watching all bug changes.

1 53

[Bug 18207] New: smart-rules.pl should validate that all branches / patron categories / item types are covered by circ rules.
by bugzilla-daemon＠bugs.koha-community.org 12 Jan '24

12 Jan '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=18207 Bug ID: 18207 Summary: smart-rules.pl should validate that all branches / patron categories / item types are covered by circ rules. Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Staff Client Assignee: koha-bugs(a)lists.koha-community.org Reporter: barton(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com At present, It's possible to have combinations of branch / category / item type that are not covered by circulation rules. This may cause issues with circulation, holds and fines; we should require that all are covered. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 6

[Bug 18054] New: Refreshing the screen for a confirmed checkout can cause odd results ( item checked out and waiting on hold)
by bugzilla-daemon＠bugs.koha-community.org 11 Jan '24

11 Jan '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=18054 Bug ID: 18054 Summary: Refreshing the screen for a confirmed checkout can cause odd results (item checked out and waiting on hold) Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: nick(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com To recreate: 1 - Place a hold and confirm it to mark waiting 2 - Checkout that item to another patron and override the hold 3 - Leave that window open 4 - In a new tab checkin the item and confirm the hold as waiting 5 - Refresh the tab from #3 - the item checksout but waiting hold does not revert -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 1