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

[Bug 21847] New: OAI-PMH server should enforce correct syntax for identifiers (including OAI-PMH:archiveID)
by bugzilla-daemon＠bugs.koha-community.org 13 Sep '23

13 Sep '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=21847 Bug ID: 21847 Summary: OAI-PMH server should enforce correct syntax for identifiers (including OAI-PMH:archiveID) Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Web services Assignee: koha-bugs(a)lists.koha-community.org Reporter: dcook(a)prosentient.com.au QA Contact: testopia(a)bugs.koha-community.org According to http://www.openarchives.org/OAI/2.0/guidelines-oai-identifier.htm, OAI-PMH identifier must follow this format: oai-identifier = scheme ":" namespace-identifier ":" local-identifier scheme = "oai" namespace-identifier = domainname-word "." domainname domainname = domainname-word [ "." domainname ] domainname-word = alpha *( alphanum | "-" ) local-identifier = 1*uric At the moment in Koha you can put whatever you like in OAI-PMH:archiveID and make all sorts of invalid identifiers. We should change this. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 3

[Bug 26596] New: koha-upgrade-schema should check version before calling updatedatabase.pl
by bugzilla-daemon＠bugs.koha-community.org 13 Sep '23

13 Sep '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26596 Bug ID: 26596 Summary: koha-upgrade-schema should check version before calling updatedatabase.pl Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: koha-bugs(a)lists.koha-community.org Reporter: dcook(a)prosentient.com.au QA Contact: testopia(a)bugs.koha-community.org At the moment, koha-upgrade-schema indiscriminately runs updatedatabase.pl, regardless of whether or not the Koha instance actually requires a database upgrade. I've noted that running koha-upgrade-schema against a large number of instances (e.g. 50 instances) takes a couple of minutes. Jonathan has noted doing an upgrade will take 1.5 seconds, so 1.5 x 50 = would be 1.25 minutes. Jonathan and I agreed via email that koha-upgrade-schema should do a check similar to C4::Auth::_version_check but without using the ORM via C4::Context->preference() to avoid the overhead of loading the DBIC schema. In theory, koha-upgrade-schema should be able to spin through 50 instances in a fraction of a second, if none of them need database upgrades. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 5

[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

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 ---------------------------------------------------------------------------- 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