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

[Bug 34242] New: Split checkouts in OPAC in normal and onsite checkouts like for reading history
by bugzilla-daemon＠bugs.koha-community.org 09 Jul '23

09 Jul '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=34242 Bug ID: 34242 Summary: Split checkouts in OPAC in normal and onsite checkouts like for reading history Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: katrin.fischer(a)bsz-bw.de QA Contact: testopia(a)bugs.koha-community.org I am not sure if that was always the case, but right now there is no way to distinguish on-site checkouts from normal checkouts in the checkouts tab in the OPAC. You can only see it in the checkout history, if enabled. As you can't see the difference at all I am marking this as a bug. -- You are receiving this mail because: You are watching all bug changes.

1 1

[Bug 34241] New: Editing an authority from the authority search popup should return you to result list
by bugzilla-daemon＠bugs.koha-community.org 09 Jul '23

09 Jul '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=34241 Bug ID: 34241 Summary: Editing an authority from the authority search popup should return you to result list Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Cataloging Assignee: koha-bugs(a)lists.koha-community.org Reporter: katrin.fischer(a)bsz-bw.de QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl When using the authority liking plugin in cataloguing you can edit authorities from the result list. But when you save your changes, you are stuck on the detail view of the authority with no option to return to the search form or even - previous result list. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 0

[Bug 34239] New: Koha-to-MARC mappings don't let you map uppercase subfield codes
by bugzilla-daemon＠bugs.koha-community.org 09 Jul '23

09 Jul '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=34239 Bug ID: 34239 Summary: Koha-to-MARC mappings don't let you map uppercase subfield codes Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Keywords: regression Severity: normal Priority: P5 - low Component: System Administration Assignee: koha-bugs(a)lists.koha-community.org Reporter: katrin.fischer(a)bsz-bw.de QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com I am a little late noticing maybe, but: Before we made the default framework authoritative for Koha-to-MARC mappings and removed the option to map in the framework configuratoin pages, you could map uppercase subfields to database fields with no issue. But now forced to use the Koha-to-MARC mappings page, this is no longer possible. There will be no error, just the mapping is not daved. Tested with 952 C trying to map to items.permanent_location. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 2

[Bug 13246] Item edit doesn't defaults to DefaultClassificationSource if not set
by bugzilla-daemon＠bugs.koha-community.org 09 Jul '23

09 Jul '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=13246 Katrin Fischer <katrin.fischer(a)bsz-bw.de> changed: What |Removed |Added ---------------------------------------------------------------------------- Summary|Item edit doesn't respect |Item edit doesn't defaults |cn_source if not defined |to | |DefaultClassificationSource | |if not set -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 13246] Item edit doesn't respect cn_source if not defined
by bugzilla-daemon＠bugs.koha-community.org 09 Jul '23

09 Jul '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=13246 Katrin Fischer <katrin.fischer(a)bsz-bw.de> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |WONTFIX --- Comment #3 from Katrin Fischer <katrin.fischer(a)bsz-bw.de> --- Still appears to be intended behaviour for me :) Please reopen if you disagree! -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 13209] Show hold wait time estimate in OPAC
by bugzilla-daemon＠bugs.koha-community.org 09 Jul '23

09 Jul '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=13209 --- Comment #2 from Katrin Fischer <katrin.fischer(a)bsz-bw.de> --- There is a lot that might influence this... local holds priority, renewals allowed if more items available, ... -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 0

[Bug 29947] New: Show an estimated waiting time when placing hold in OPAC
by bugzilla-daemon＠bugs.koha-community.org 09 Jul '23

09 Jul '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=29947 Bug ID: 29947 Summary: Show an estimated waiting time when placing hold in OPAC Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Hold requests Assignee: koha-bugs(a)lists.koha-community.org Reporter: magnus(a)libriotech.no QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com Do some calculation based on number of holds and max loan period. Would have to take decreaseLoanHighHolds into account too. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 1

[Bug 13209] Show hold wait time estimate in OPAC
by bugzilla-daemon＠bugs.koha-community.org 09 Jul '23

09 Jul '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=13209 Katrin Fischer <katrin.fischer(a)bsz-bw.de> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |magnus(a)libriotech.no --- Comment #1 from Katrin Fischer <katrin.fischer(a)bsz-bw.de> --- *** Bug 29947 has been marked as a duplicate of this bug. *** -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 0

[Bug 13171] Check box for email is missing for hold notifications in patron messaging preferences.
by bugzilla-daemon＠bugs.koha-community.org 09 Jul '23

09 Jul '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=13171 Katrin Fischer <katrin.fischer(a)bsz-bw.de> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|REOPENED |RESOLVED Resolution|--- |WONTFIX --- Comment #17 from Katrin Fischer <katrin.fischer(a)bsz-bw.de> --- I know there was some problematic update in one of the earlier versions that left you with incomplete entries in the messaging preferences tables, but it happened very rarely and not consistently for every installation. I believe given to age and it not being a reoccuring event, we can close this. Please reopen if you disagree. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 0

[Bug 13165] Don't trigger holds when patrons have already reached limit of checkouts
by bugzilla-daemon＠bugs.koha-community.org 09 Jul '23

09 Jul '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=13165 Katrin Fischer <katrin.fischer(a)bsz-bw.de> changed: What |Removed |Added ---------------------------------------------------------------------------- Summary|Active Hold Limit |Don't trigger holds when | |patrons have already | |reached limit of checkouts --- Comment #5 from Katrin Fischer <katrin.fischer(a)bsz-bw.de> --- I am not sure if we could make this transparent to the user. They might just assume that they can return items prior to picking up their holds and I would think that of a valid use of the system - timing their visit to the library to do both things. And we can limit the amount of holds a patron can place too... Not sure if that would not overcomplicate. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 0