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

[Bug 31654] New: Hide non-public libraries from MastheadLibraryPulldown
by bugzilla-daemon＠bugs.koha-community.org 04 Nov '22

04 Nov '22

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=31654 Bug ID: 31654 Summary: Hide non-public libraries from MastheadLibraryPulldown Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: new feature Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: domm(a)plix.at QA Contact: testopia(a)bugs.koha-community.org We have a few internal libraries (branches) that are used by librarians, but should not be visible to "normal" patrons (mostly because they cannot access those books). Currently there is no way to hide a library from the Masthead Pulldown or in the advanced search. Bug 27360 introduced the flag branches.public. This could be used to also hide the library from MastheadPulldown and the AdvancedSearch List. It seems that there is some additional / similar work going on in Bug 12242 Can we submit a patch that uses branches.public to hide libraries? Or should we wait what 27360 and 12242 will bring? Or can/should we also work on those tickets? -- You are receiving this mail because: You are watching all bug changes.

1 25

[Bug 29102] New: DecreaseLoanHighHolds will decrease lona period if borrower has an 'unfound' hold
by bugzilla-daemon＠bugs.koha-community.org 04 Nov '22

04 Nov '22

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=29102 Bug ID: 29102 Summary: DecreaseLoanHighHolds will decrease lona period if borrower has an 'unfound' hold Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Hold requests 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 Similar to bug 25566 If a patron has a hold on a record and there are other holds -the hold is not found -the rules limit to 1 hold per record -no items will be holdable (already have the hone hold) -Loan will be decreased if using decreaseLoanHighHoldsControl - 'over the number of holdable items'/dynamic -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 28

[Bug 31987] New: Update plugin unimarc_field_110.pl fields
by bugzilla-daemon＠bugs.koha-community.org 04 Nov '22

04 Nov '22

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=31987 Bug ID: 31987 Summary: Update plugin unimarc_field_110.pl fields Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Cataloging Assignee: koha-bugs(a)lists.koha-community.org Reporter: thibaud.guillot(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl Actually some fields are missing in plugin unimarc_field_110 it could be great to update it -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 13

[Bug 27259] New: HomeOrHoldingBranch is not used in all places
by bugzilla-daemon＠bugs.koha-community.org 04 Nov '22

04 Nov '22

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=27259 Bug ID: 27259 Summary: HomeOrHoldingBranch is not used in all places Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: koha-bugs(a)lists.koha-community.org Reporter: joonas.kylmala(a)helsinki.fi QA Contact: testopia(a)bugs.koha-community.org If you grep for CircControl in Koha source code you will find that there are few places that are missing the check for HomeOrHoldingBranch and just use item's homebranch. This for example leads to calculating renewability and fines with rules from item's homebranch and not from the holdingbranch as was wanted. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 30

[Bug 11300] Add a new authority linker which searches for authority links on a Z39.50 server.
by bugzilla-daemon＠bugs.koha-community.org 04 Nov '22

04 Nov '22

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11300 Shi Yao Wang <shi-yao.wang(a)inLibro.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #141168|0 |1 is obsolete| | --- Comment #46 from Shi Yao Wang <shi-yao.wang(a)inLibro.com> --- Created attachment 143292 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=143292&action=e… Bug 11300: Add a new authority linker which searches for authority links on a Z39.50 server. This patch adds a Z39.50 Linker which searches for authority links on a remote server. If a matching authority is found, it's imported in the local database for linking with the current biblio record. If no matching authority was found on the remote server, the Linker falls back to a local authority search. Configuration : * The option "Z39.50 Server" is added to the LinkerModule preference. You must choose this to use the new Linker. * The preference LinkerZ3950Server is required and specifies which server to use for linking. It must contain the "name" of the server, as defined in the z3950servers table. * You can set the "local_first" option in the LinkerOptions preference to force the Linker to search for authorities in the local database first. If no local authority match was found, the Linker falls back to a remote Z39.50 search. Sponsored-by: CCSR ( http://www.ccsr.qc.ca ) -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 23644] New: Update linked patron accounts when one account is updated
by bugzilla-daemon＠bugs.koha-community.org 04 Nov '22

04 Nov '22

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23644 Bug ID: 23644 Summary: Update linked patron accounts when one account is updated 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 It would be a timesaver to have guarantee accounts automatically update when a guarantor account is updated. We are thinking the following would be good parameters for this: * When a guarantor or guarantee account is updated, have Koha check for connected accounts. * If detected, a checkbox is added to the edit screen to "Update connected accounts" * Upon saving the record, if the checkbox is checked, Koha will present an edit screen for each of the connected accounts, with the fields pre-populated with the updated information from the original edit screen. Staff can then choose to save the record as is, or modify each field as necessary (for instance, if each person had their own unique email address) Basically, we want to have Koha do the heavy lifting of updating multiple guarantee accounts at once instead of doing it ourselves. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 4

[Bug 5463] limit to available shows on hold items
by bugzilla-daemon＠bugs.koha-community.org 04 Nov '22

04 Nov '22

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5463 Carolyn Hughesman <chughesman(a)cclsny.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |chughesman(a)cclsny.org --- Comment #6 from Carolyn Hughesman <chughesman(a)cclsny.org> --- +1 This is frustrating to our patrons as well. -- You are receiving this mail because: You are the QA Contact for the bug. You are watching all bug changes.

1 0

[Bug 24387] New: Rename News tool
by bugzilla-daemon＠bugs.koha-community.org 04 Nov '22

04 Nov '22

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=24387 Bug ID: 24387 Summary: Rename News tool 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 Now that the 'News' tool serves a larger purpose than just adding news, we should rename it. I suggest 'Content' or 'Custom content'. But it's just a suggestion. Feel free to change it to something else. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 113

[Bug 32107] New: Send $self to Plugins->call and call discard_changes inside
by bugzilla-daemon＠bugs.koha-community.org 04 Nov '22

04 Nov '22

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32107 Bug ID: 32107 Summary: Send $self to Plugins->call and call discard_changes inside Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Plugin architecture Assignee: koha-bugs(a)lists.koha-community.org Reporter: m.de.rooy(a)rijksmuseum.nl QA Contact: testopia(a)bugs.koha-community.org Resulting from a discussion on IRC and in the QA team. If there is a need for further discussion, we can continue here. The idea is: We should no longer $self->store and pass $self->get_from_storage to the ->call routine. But we should $self->store, pass $self to Plugins->call, and ->discard_changes once inside ->call to fetch timestamps and default values from DBMS. What happens after ->call? Currently, we pass a copy but continue afterwards with the old $self. Normally, we wont do much more, but this might create side-effects since we do not operate on the latest data (we ignore changes from plugins). If we pass $self, we have the latest state back after ->call. Though we are not sure if the plugin(s) did a store. If we would do a discard after the plugins loop in ->call, we actually ignore unsaved changes like we do now too and we do not disturb the plugins loop inside ->call. To make it even more explicit, we could add a parameter to ->call that controls if we do or do not discard after the plugins loop.. Side note: The execution order of plugins seems to be database insert order when I look at the code in GetPlugins. Theoretically I would rather control that differently but that could be a topic of another report. Not in this scope ;) -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 6

[Bug 5463] limit to available shows on hold items
by bugzilla-daemon＠bugs.koha-community.org 03 Nov '22

03 Nov '22

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5463 George Williams (NEKLS) <george(a)nekls.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |george(a)nekls.org --- Comment #5 from George Williams (NEKLS) <george(a)nekls.org> --- +1 -- You are receiving this mail because: You are watching all bug changes. You are the QA Contact for the bug.

1 0