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

[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

[Bug 8948] MARC21 field 787 doesn't display
by bugzilla-daemon＠bugs.koha-community.org 03 Nov '22

03 Nov '22

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8948 Andrew Fuerste-Henry <andrewfh(a)dubcolib.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #143111|0 |1 is obsolete| | --- Comment #27 from Andrew Fuerste-Henry <andrewfh(a)dubcolib.org> --- Created attachment 143143 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=143143&action=e… Bug 8948 (follow-up) Correct OPAC link Signed-off-by: Andrew Fuerste-Henry <andrewfh(a)dubcolib.org> -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 8948] MARC21 field 787 doesn't display
by bugzilla-daemon＠bugs.koha-community.org 03 Nov '22

03 Nov '22

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8948 Andrew Fuerste-Henry <andrewfh(a)dubcolib.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #143084|0 |1 is obsolete| | --- Comment #26 from Andrew Fuerste-Henry <andrewfh(a)dubcolib.org> --- Created attachment 143142 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=143142&action=e… Bug 8948: Changes for OPAC Test with same record, confirm OPAC view is as expected Signed-off-by: Andrew Fuerste-Henry <andrewfh(a)dubcolib.org> -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 8948] MARC21 field 787 doesn't display
by bugzilla-daemon＠bugs.koha-community.org 03 Nov '22

03 Nov '22

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8948 Andrew Fuerste-Henry <andrewfh(a)dubcolib.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #143083|0 |1 is obsolete| | --- Comment #25 from Andrew Fuerste-Henry <andrewfh(a)dubcolib.org> --- Created attachment 143141 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=143141&action=e… Bug 8948: Display MARC 787 relationship field This field is defined similar to 775, as a related work: https://www.loc.gov/marc/bibliographic/bd787.html This patch adds a display of this field, linking to the referenced record as the 775 does It also tests for 580 field, and displays the text there if present, using the 787 a and t subfields otherwise To test: 1 - Edit the default framework to make 787atw and 580a visible in editor 2 - Add a 787 to a record: $tThe ideas behind the chess openings $aFine, Reuben< $w2470231 3 - Confirm there is no display 4 - Apply patch / restart all 5 - 'Other related works' now shows 6 - Link should be using title of record 7 - Set system preference UseControlNumber to Use 8 - Reload details, link should now use control number 9 - Add a 580 to the record: $a This is a friendly work to this one 10 - Confirm the text of the link now displays before the link 11 - Add a second 580, confirm it displays as well - there is no seperator as each should end with a period or other punctuation according to MARC - there is a dpan with a class surrounding each so styling can be added as desired 12 - Add a second 787 - confirm seperator present and wrapped in a span with a class - confirm each 787 is shown with a span/class for styling Signed-off-by: Andrew Fuerste-Henry <andrewfh(a)dubcolib.org> -- You are receiving this mail because: You are watching all bug changes.

1 0