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

[Bug 17453] New: Inter-site holds
by bugzilla-daemon＠bugs.koha-community.org 22 Sep '23

22 Sep '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17453 Bug ID: 17453 Summary: Inter-site holds Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: ASSIGNED Severity: enhancement Priority: P5 - low Component: Circulation Assignee: jonathan.druart(a)bugs.koha-community.org Reporter: jonathan.druart(a)bugs.koha-community.org QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com -- You are receiving this mail because: You are watching all bug changes.

1 46

[Bug 16883] New: TT syntax for notices should take aqorders, aqbooksellers , biblioitems tables into account
by bugzilla-daemon＠bugs.koha-community.org 19 Sep '23

19 Sep '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=16883 Bug ID: 16883 Summary: TT syntax for notices should take aqorders, aqbooksellers, biblioitems tables into account Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Notices Assignee: koha-bugs(a)lists.koha-community.org Reporter: jonathan.druart(a)bugs.koha-community.org QA Contact: testopia(a)bugs.koha-community.org Depends on: 14757 Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14757 [Bug 14757] Allow the use of Template Toolkit syntax for slips and notices -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 3

[Bug 18159] New: Show patron permissions on the moremember page
by bugzilla-daemon＠bugs.koha-community.org 18 Sep '23

18 Sep '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=18159 Bug ID: 18159 Summary: Show patron permissions on the moremember page Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Patrons Assignee: koha-bugs(a)lists.koha-community.org Reporter: aleishaamohia(a)hotmail.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com ... so they are more easily read. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 4

[Bug 17350] New: Add option to delete data stored in saved_reports
by bugzilla-daemon＠bugs.koha-community.org 16 Sep '23

16 Sep '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17350 Bug ID: 17350 Summary: Add option to delete data stored in saved_reports Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Reports Assignee: gmcharlt(a)gmail.com Reporter: katrin.fischer(a)bsz-bw.de QA Contact: testopia(a)bugs.koha-community.org This is a follow-up bug to bug 14435 which reactivates an old feature that allows you to store the results of a run report in saved_reports. Now that this will work again, there should also be an option to clean up the data stored - either from the script, the GUI or ideally from both. -- You are receiving this mail because: You are watching all bug changes.

1 23

[Bug 16820] New: add possibility to edit fines
by bugzilla-daemon＠bugs.koha-community.org 13 Sep '23

13 Sep '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=16820 Bug ID: 16820 Summary: add possibility to edit fines Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: marjorie.barry-vila(a)ccsr.qc.ca QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com Hi, It would be great to have to edit fines if a mistake is made in the amount or in the notes. Regards, Marjorie -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 25

[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 16514] New: Force scalar cotext where param assumes a list incorrectly in admin/edi scripts
by bugzilla-daemon＠bugs.koha-community.org 11 Sep '23

11 Sep '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=16514 Bug ID: 16514 Summary: Force scalar cotext where param assumes a list incorrectly in admin/edi scripts Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Acquisitions Assignee: koha-bugs(a)lists.koha-community.org Reporter: colin.campbell(a)ptfs-europe.com QA Contact: testopia(a)bugs.koha-community.org CGI's param method assumes a list context when lvalue not explicitly scalar. Force the correct context to avoid errors being logged -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 13

[Bug 18158] New: Make SIP2 title identifier (AJ) customizable within sipconfig.xml
by bugzilla-daemon＠bugs.koha-community.org 11 Sep '23

11 Sep '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=18158 Bug ID: 18158 Summary: Make SIP2 title identifier (AJ) customizable within sipconfig.xml Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: new feature Priority: P5 - low Component: SIP2 Assignee: koha-bugs(a)lists.koha-community.org Reporter: barton(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: colin.campbell(a)ptfs-europe.com Feature Request: Add the ability to customize SIP2 title identifier (AJ) returned in Checkout Response (12) Checkin Response(10) Item Information Response (18) Hold Response (16) Renew Response (30) The formatting could be done by adding template toolkit code to sipconfig.xml, as was done in Bug 16755 - allow SIP2 field DA ( hold patron name ) to be customized. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 3

[Bug 18161] New: Option to completely disable advance notice on loans with auto renewal
by bugzilla-daemon＠bugs.koha-community.org 11 Sep '23

11 Sep '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=18161 Bug ID: 18161 Summary: Option to completely disable advance notice on loans with auto renewal Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Notices Assignee: koha-bugs(a)lists.koha-community.org Reporter: stefan.berndtsson(a)ub.gu.se QA Contact: testopia(a)bugs.koha-community.org Some background. In our current library system, we use long loans (loans with a guaranteed minimum due date, but a much much longer hard due date), with a recall function. This is only in use for parts of the content. Koha does not support this, so we're looking at using auto renewal as a method to give a reasonable resemblance of long loans. We also want advance notices to be sent when the due date is about to arrive, but having an advance notice and then an automatic renewal shortly after will produce a multitude of notices that will be considered as faulty by the end user. The suggested solution to this is an option to simply disable advance notices for loans where auto renewal is active. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 7

[Bug 18265] New: Followup to Buuug 17196. deletedbiblio_metadata is not used. biblioitemnumber was forgot.
by bugzilla-daemon＠bugs.koha-community.org 11 Sep '23

11 Sep '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=18265 Bug ID: 18265 Summary: Followup to Buuug 17196. deletedbiblio_metadata is not used. biblioitemnumber was forgot. Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Cataloging Assignee: gmcharlt(a)gmail.com Reporter: olli-antti.kivilahti(a)jns.fi QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl Exhibit 1: The MARCXML is lost when the biblio is deleted because the values in biblio_metadata-table from biblioitems-table are never moved to deletedbiblio_metadata-table. Previously the marcxml was preserved in the oldbiblioitems-table This is a challenge for gathering statistics For example item has been ordered, received, and removed from collection during the statistics period Information in marcxml is needed to accurately categorize the item Exhibit 2: [15:22:38] <kivilahtio> also. In Koha there once was a great idea that one biblio-entry can have multiple biblioitems [15:22:45] <kivilahtio> and the marcxml was tied to the biblioitems-table [15:23:11] <kivilahtio> this is a nice idea, but nobdy really cared for it and now biblionumber and biblioitemnumber are used interchangeably [15:23:22] <kivilahtio> except when they get out of sync during a data migration [15:23:41] <kivilahtio> then things start to work really interestingly [15:23:47] <kivilahtio> but the point is [15:23:57] <kivilahtio> biblio_metadata has a biblionumber-column [15:24:15] <kivilahtio> shouldn't it have a biblioitemnumber-column, just for old time's sake? In the biblioitems-table we had marcxml. primary keyed with biblioitemnumber. Now the marcxml is moved to biblio_metadata and the foreign key reference was simplified to biblionumber. This makes the existing FRBR-bug worse. -- You are receiving this mail because: You are watching all bug changes.

1 27