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

[Bug 14156] Add id tags to each MARC note in the display
by bugzilla-daemon＠bugs.koha-community.org 12 Sep '23

12 Sep '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14156 David Nind <david(a)davidnind.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #154422|0 |1 is obsolete| | --- Comment #6 from David Nind <david(a)davidnind.com> --- Created attachment 155577 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=155577&action=e… Bug 14156: Add id tags to each MARC note in the display This patch adds tag number to the data which is returned by $biblio->get_marc_notes(). The bibliographic detail page in the staff client is modified to use the tag number in both a class (for consistent styling across the same tag number) and id (for unique styling for each repeated tag). To test, apply the patch and restart services. - As a quick test for custom CSS, go to Administration -> System preferences and locate the IntranetUserCSS preference. - Add this testing CSS: .marcnote { font-size:140%; font-family: serif; } .marcnote-500 { background-color: #66FFCC; } .marcnote-511 { background-color: #99FFFF; } .marcnote-520 { background-color: #CCFF00; } .marcnote-521 { background-color: #CCFFFF; } .marcnote-538 { background-color: #FFCCCC; } .marcnote-546 { background-color: #FFFFCC; } - Locate a record with multiple notes fields. In the sample data, record 46, "Viridiana" is a good example which works well with the above CSS. - On the bibliographic detail page for the record, click the "Descriptions" tab. - Each MARC note should be colored according to the tag it comes from. - Inspect the HTML to confirm that each paragraph also has its own unique ID. Signed-off-by: David Nind <david(a)davidnind.com> -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 14156] Add id tags to each MARC note in the display
by bugzilla-daemon＠bugs.koha-community.org 12 Sep '23

12 Sep '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14156 David Nind <david(a)davidnind.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Needs Signoff |Signed Off -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 13870] Add subscription and order count to new batch record deletion tool
by bugzilla-daemon＠bugs.koha-community.org 12 Sep '23

12 Sep '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=13870 Émily-Rose Francoeur <emily-rose.francoeur(a)inLibro.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #152236|0 |1 is obsolete| | --- Comment #5 from Émily-Rose Francoeur <emily-rose.francoeur(a)inLibro.com> --- Created attachment 155576 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=155576&action=e… Bug 13870: Add columns in batch delete mode Signed-off-by: Émily-Rose Francoeur <emily-rose.francoeur(a)inLibro.com> -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 13870] Add subscription and order count to new batch record deletion tool
by bugzilla-daemon＠bugs.koha-community.org 12 Sep '23

12 Sep '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=13870 Émily-Rose Francoeur <emily-rose.francoeur(a)inLibro.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Needs Signoff |Signed Off -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 32515] New: SIP2 no block flag on checkin calls routine that does not exist
by bugzilla-daemon＠bugs.koha-community.org 12 Sep '23

12 Sep '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32515 Bug ID: 32515 Summary: SIP2 no block flag on checkin calls routine that does not exist Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: SIP2 Assignee: koha-bugs(a)lists.koha-community.org Reporter: nick(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org git grep "checkin_no_block" C4/SIP/Sip/MsgType.pm: $status = $ils->checkin_no_block( $item_id, $trans_date, $return_date, $item_props, $cancel ); -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 26

[Bug 18117] New: Convert browser alerts to modals
by bugzilla-daemon＠bugs.koha-community.org 12 Sep '23

12 Sep '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=18117 Bug ID: 18117 Summary: Convert browser alerts to modals 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: cbrannon(a)cdalibrary.org QA Contact: testopia(a)bugs.koha-community.org With modals becoming more active in Koha, I think we need to move away from alert messages and stick with modals. Alert messages look different from browser to browser, and you have less/no control over the look and feel of the alert. Modals would allow for more enhancement, such as color and sound, if someone chose that. The big concern is consistency. We lack consistency between alerts and modals, and with alerts between browsers. I would proposed a stop on use of alert messages, and convert existing uses of alerts to modal. That's my opinion. Would like to hear others. -- You are receiving this mail because: You are watching all bug changes.

1 12

[Bug 30575] New: Returning an ILL item shouldn't just change the request status
by bugzilla-daemon＠bugs.koha-community.org 12 Sep '23

12 Sep '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=30575 Bug ID: 30575 Summary: Returning an ILL item shouldn't just change the request status 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: tomascohen(a)gmail.com In the context of more complex ILL backends, in which returning an item could imply, for example, notifying an external source it is just not enough to call $req->status('RET')->store We should be calling something like ->backend_return instead, as we do with other actions, and let the plugin handle it however they need to. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 5

[Bug 12141] On Display Module
by bugzilla-daemon＠bugs.koha-community.org 12 Sep '23

12 Sep '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12141 Sally Lodico <Slodico(a)knoxlib.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |Slodico(a)knoxlib.org --- Comment #22 from Sally Lodico <Slodico(a)knoxlib.org> --- +1 Yes please. Right now all of our circ staff have permission to bulk edit the location field, which isn't ideal, but it's the only option we had. A display module would be grand. -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 32627] New: Reprinting holds slips should not reset the expiration date
by bugzilla-daemon＠bugs.koha-community.org 12 Sep '23

12 Sep '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32627 Bug ID: 32627 Summary: Reprinting holds slips should not reset the expiration date 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: Laura.escamilla(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com Occasionally, the slips in items waiting on the holds shelf tend to get pulled out. When this happens, library staff check in items to reprint the slips. Previous to the latest upgrade the holds expiration date would remain the same, but now the expiration date is being calculated based on the NEW date the item is checked in. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 20

[Bug 34766] New: Searching for URIs in MARC fields could be improved
by bugzilla-daemon＠bugs.koha-community.org 12 Sep '23

12 Sep '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=34766 Bug ID: 34766 Summary: Searching for URIs in MARC fields could be improved 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: m.de.rooy(a)rijksmuseum.nl QA Contact: testopia(a)bugs.koha-community.org In Zebra we currently have this index: <index_subfields tag="952" subfields="u"> <target_index>uri:u</target_index> </index_subfields> It seems to be connected only to items.uri however. The generic index name would suggest a broader range. Or perhaps, allow a broader range? We still have one other specific uri indexed: <index_subfields tag="024" subfields="a" condition="marc:subfield[@code='2' and text()='uri']"> <target_index>Identifier-other:u</target_index> </index_subfields> Two popular MARC fields for URIs, 520$u and 856$u are not indexed in a specific index. How about adding them to uri ? Since we do now have uri bound to items, do we need a specific subindex (like item_uri) for that one? Or the other way around, given that uri is already taken, why not add generic_uri or any other (better) new index name? And still elaborating here, a urx search does not really work in Koha. Several special characters in URLs seem to return nothing, since C4/Search does not like them probably. (While the search works in yaz-client.) Should we make it possible to search those just like other text fields too? If I am looking for a record containing a URL like sub.domain.country, why not look for a word in the string like sub or domain? -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 2