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

[Bug 26314] New: "Volumes: show volumes" showing regardless of whether there are volumes linked to the record
by bugzilla-daemon＠bugs.koha-community.org 12 Dec '24

12 Dec '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26314 Bug ID: 26314 Summary: "Volumes: show volumes" showing regardless of whether there are volumes linked to the record 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 Depends on: 15851 When cataloguing multi part records with sets and volumes, we currently show a link to "Show volumes" on the set record. The link is always shown on a set record, even if there are no linked volumes. Bug 15851 solves the same issue for analytics. volumes would be a great next step. At the moment Show volumes is only shown on monographs, but we could add the feature for serial records as well. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15851 [Bug 15851] "Analytics: Show analytics" showing regardless of whether they have analytics -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 98

[Bug 20202] New: Link EDI account to Create Edi order
by bugzilla-daemon＠bugs.koha-community.org 12 Dec '24

12 Dec '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20202 Bug ID: 20202 Summary: Link EDI account to Create Edi order Change sponsored?: --- Product: Koha Version: 17.05 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Acquisitions Assignee: koha-bugs(a)lists.koha-community.org Reporter: cunha(a)monterey.org QA Contact: testopia(a)bugs.koha-community.org Currently to send create an EDI order you click "Create EDIFACT order" and are taken to a page to select, if you have multiple EDI accounts, your vendor account from a drop-down menu. It would be great if the Vendor and EDI account could be linked, so there would be no possibility of sending the order to the wrong account. We started with the ByWater beta version of EDI, that was the way it worked in beta. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 5

[Bug 27365] New: Koha doesn't check marcxml field size is < 10000 and fails in various places
by bugzilla-daemon＠bugs.koha-community.org 12 Dec '24

12 Dec '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=27365 Bug ID: 27365 Summary: Koha doesn't check marcxml field size is < 10000 and fails in various places Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: MARC Bibliographic data support Assignee: koha-bugs(a)lists.koha-community.org Reporter: didier.gautheron(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org Hi ISO standard >The core of the framework is a MARCXML schema that allows lossless round-trip >conversion of an ISO 2709 MARC 21 record and an XML-encoded MARC 21 record. Thus a field size is 9999 bytes max. But /usr/share/perl5/MARC/File/USMARC.pm doesn't care: my $direntry = sprintf( "%03s%04d%05d", $field->tag, $len, $dataend ); and if len >= 10000 it silently creates a bogus directory with a length of 13 rather then 12. These non-conformed marxml will fail in various places. Export, search results list with elasticsearch which store ISO 2709 record in index and use them as data source in results list. eg: Easy to trigger in french UNIMARC with 359 (sorry in french) https://www.transition-bibliographique.fr/wp-content/uploads/2019/02/B359-2… -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 55

[Bug 17600] New: Standardize the EXPORT
by bugzilla-daemon＠bugs.koha-community.org 11 Dec '24

11 Dec '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17600 Bug ID: 17600 Summary: Standardize the EXPORT Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: ASSIGNED Severity: enhancement Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: jonathan.druart(a)bugs.koha-community.org Reporter: jonathan.druart(a)bugs.koha-community.org QA Contact: testopia(a)bugs.koha-community.org On bug 17591 we discovered that there was something weird going on with the way we export and use subroutines/modules. I tried to standardize our EXPORT to use EXPORT_OK only. -- You are receiving this mail because: You are watching all bug changes.

1 215

[Bug 16694] New: Limit SIP2 auth by patron attribute
by bugzilla-daemon＠bugs.koha-community.org 10 Dec '24

10 Dec '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=16694 Bug ID: 16694 Summary: Limit SIP2 auth by patron attribute Change sponsored?: Sponsored Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Authentication Assignee: magnus(a)libriotech.no Reporter: magnus(a)libriotech.no QA Contact: testopia(a)bugs.koha-community.org CC: dpavlin(a)rot13.org In Scandinavia "more open" (Swedish: "Meröppet", Norwegian: "Meråpent") is a hot issue at the moment. What this means is that patrons can use their card and password/PIN to lock themselves into the library even when staff is not around. Typically, this means that patrons can get access to the library building from 7 am to 11 pm, even if the library is only staffed from 8 am to 5 pm. Typically, SIP2 is used to communnicate between the "more open"-system and the ILS, specifically to authenticate the user with a username and password/PIN. Also, you want the ability to turn "more open" access on and off for patrons. An extended patron attribute with possible values of NULL/empty, 0 or 1 should serve well for this. SIP2 does not have a field for saying "this is a moreopen login", so we need a way to identify a SIP2 user as a moreopen user. My plan is to add another attribute to the login element in SIPConfig.xml to achieve this: <login id="koha" password="koha" delimiter="|" error-detect="enabled" institution="kohalibrary" patron-attribute="MEROPPET" /> "MEROPPET" is then the name of an extended patron attribute which can be set to NULL or 0 (patron should not have access to moreopen) or 1 (patron should have access). This should be flexible enough to allow other, similar schemes to use some other patron attribute. -- You are receiving this mail because: You are watching all bug changes.

1 43

[Bug 25813] New: Enhance patron expiration in SIP display
by bugzilla-daemon＠bugs.koha-community.org 10 Dec '24

10 Dec '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25813 Bug ID: 25813 Summary: Enhance patron expiration in SIP display Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: SIP2 Assignee: koha-bugs(a)lists.koha-community.org Reporter: matthias.meusburger(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org CC: colin.campbell(a)ptfs-europe.com Currently, the patron information returned by SIP only shows "PATRON EXPIRED" when the patron card has expired. This patch makes the display more consistant with the Opac display and also complies with the NotifyBorrowerDeparture system preference. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 23

[Bug 25754] New: Deprecate C4::Items::ModItemTransfer
by bugzilla-daemon＠bugs.koha-community.org 06 Dec '24

06 Dec '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25754 Bug ID: 25754 Summary: Deprecate C4::Items::ModItemTransfer 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: martin.renvoize(a)ptfs-europe.com QA Contact: testopia(a)bugs.koha-community.org CC: koha-bugs(a)lists.koha-community.org, testopia(a)bugs.koha-community.org Depends on: 25753 Blocks: 22161 C4::Items::ModItemTransfer should be replaced replaced by a combination of Koha::Item and Koha::Item::Transfer methods. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=22161 [Bug 22161] Move C4::Circulation::transferbook and C4::Items::ModItemTransfer to Koha namespace https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25753 [Bug 25753] Deprecate C4::Circulation::transferbook -- You are receiving this mail because: You are the assignee for the bug. You are on the CC list for the bug. You are watching all bug changes.

1 12

[Bug 17976] New: TT syntax for notices - Add an equivalence for items.fine
by bugzilla-daemon＠bugs.koha-community.org 06 Dec '24

06 Dec '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17976 Bug ID: 17976 Summary: TT syntax for notices - Add an equivalence for items.fine Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: gmcharlt(a)gmail.com Reporter: jonathan.druart(a)bugs.koha-community.org QA Contact: testopia(a)bugs.koha-community.org The items.fine is a trick of our historical syntax. We need to provide a way to access this value from the a notice template using the TT syntax. -- You are receiving this mail because: You are watching all bug changes.

1 39

[Bug 22789] New: Establish Non-Priority Holds
by bugzilla-daemon＠bugs.koha-community.org 06 Dec '24

06 Dec '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=22789 Bug ID: 22789 Summary: Establish Non-Priority Holds 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: joy(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com Target Milestone: --- This development would allow holds to be placed so the hold wouldn't prevent the current checkout from renewing the hold. The goal is a better customer service because certain library departments will place holds to repair or replace a book when it is returned to the library (the internal library need has no rush), they only want the catch the book on it's return. The library needs to allow the patron who has it out have the flexibility to renew it on their account without a staff override. This functionality would be specific to the staffside only. - Add a Checkbox on the hold form that stipulates that the hold being placed is a 'non-priority' hold. - Add a field in the reserves tables to flag the hold as 'non-priority'. - The checkreserves module in Koha checks for this flag. If found, the hold request is 'ignored' and item can be renewed. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 41

[Bug 28130] New: Show list of serial email alerts a patron subscribed to in patron account in OPAC
by bugzilla-daemon＠bugs.koha-community.org 05 Dec '24

05 Dec '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28130 Bug ID: 28130 Summary: Show list of serial email alerts a patron subscribed to in patron account in OPAC Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement 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 It would be nice if a patron could see which email notifications for new serial issues they have subscribed to in the OPAC. At the moment subscribing and unsubscribing is only possible from the detail screen and this makes it somewhat hard to find for patrons. -- You are receiving this mail because: You are watching all bug changes.

1 39