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

[Bug 17981] New: Add the ability to preview generated notice templates
by bugzilla-daemon＠bugs.koha-community.org 16 Nov '21

16 Nov '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17981 Bug ID: 17981 Summary: Add the ability to preview generated notice templates Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: ASSIGNED Severity: enhancement Priority: P5 - low Component: Notices Assignee: jonathan.druart(a)bugs.koha-community.org Reporter: jonathan.druart(a)bugs.koha-community.org QA Contact: testopia(a)bugs.koha-community.org Depends on: 17961 Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17961 [Bug 17961] TT syntax for notices - Prove we have an equivalent for our historical custom syntax -- You are receiving this mail because: You are watching all bug changes.

1 96

[Bug 16872] New: You should not be allowed to deleted a record with open orders attached
by bugzilla-daemon＠bugs.koha-community.org 15 Nov '21

15 Nov '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=16872 Bug ID: 16872 Summary: You should not be allowed to deleted a record with open orders attached Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Acquisitions Assignee: koha-bugs(a)lists.koha-community.org Reporter: nick(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org Bug 10869 and Bug 10758 try to deal with the fallout from deleting a record with an order attached. I think, rather than fixing the order end we should prevent the deletion of the record in the first place to avoid causing an issue. This case also affects EDI ordering as item cannot be received when a title has been deleted -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 13

[Bug 17314] New: REST API: Add API route to create, list and delete a purchase suggestion
by bugzilla-daemon＠bugs.koha-community.org 11 Nov '21

11 Nov '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17314 Bug ID: 17314 Summary: REST API: Add API route to create, list and delete a purchase suggestion Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Web services Assignee: koha-bugs(a)lists.koha-community.org Reporter: mail(a)jkozlovsky.cz QA Contact: testopia(a)bugs.koha-community.org It would be nice to have an API for creating a purchase suggestion. It would be used for instance in VuFind. Proposed implementation: To create: POST /suggestions/{borrowernumber} Incoming data: { title (required) author copyrightdate isbn publishercode collectiontitle place itemtype patronreason note negcap } Outcoming data: 200 OK / 403 Forbidden / 409 Conflict (when already exists the proposal) { error status } To list: GET /suggestions/{borrowernumber} Outcoming data: list of suggestions To delete: DELETE /suggestions/{borrowernumber}/{suggestion_id} Outcoming data: 204 No Content (successful deletion) / 403 Forbidden / 404 Not Found -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 135

[Bug 16467] New: Discharge requests pending count should appear on patrons home page
by bugzilla-daemon＠bugs.koha-community.org 10 Nov '21

10 Nov '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=16467 Bug ID: 16467 Summary: Discharge requests pending count should appear on patrons home page 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: oleonard(a)myacpl.org QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com Currently the "Discharge requests pending" count appears only on the staff client home page. Like the count of patrons requesting modification, the discharge request count should also appear on the patrons home page (members-home.pl). -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 4

[Bug 16446] New: Allow librarians to add borrowers to lists by borrowernumber or cardnumber
by bugzilla-daemon＠bugs.koha-community.org 22 Oct '21

22 Oct '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=16446 Bug ID: 16446 Summary: Allow librarians to add borrowers to lists by borrowernumber or cardnumber Change sponsored?: --- Product: Koha Version: 3.22 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Lists Assignee: gmcharlt(a)gmail.com Reporter: liz(a)catalyst.net.nz QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl It would be nice to be able to add borrowers to lists based on a supplied list of cardnumbers or borrowernumbers (that they could get from a report, for example). -- You are receiving this mail because: You are watching all bug changes.

1 19

[Bug 18501] New: Automatic refunds need protection from failure
by bugzilla-daemon＠bugs.koha-community.org 19 Oct '21

19 Oct '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=18501 Bug ID: 18501 Summary: Automatic refunds need protection from failure Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: major Priority: P5 - low Component: Circulation 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 I am told that the auto refund feature can fail if the status is edited in the item edit screen. There should be some protection in place to keep this from failing so easily and quietly. Possible solutions might be: 1) Prevent status from being edited if a fee has been charged for that item. 2) A warning and confirmation of action when the status is being edited and there is a fee involved. 3) An authorized override for such a change. 4) A note in the patron account lines indicating status was change and an auto refund will not be possible. 5) The ability to auto refund, even after the status has been altered. I am marking this as a bug, because I cannot see how the current behavior could be a desired function. Failure is not an option. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 138

[Bug 17328] New: Koha fixes for Mysql 5.7
by bugzilla-daemon＠bugs.koha-community.org 19 Oct '21

19 Oct '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17328 Bug ID: 17328 Summary: Koha fixes for Mysql 5.7 Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: MARC Bibliographic record staging/import Assignee: gmcharlt(a)gmail.com Reporter: philippe.blouin(a)inlibro.com QA Contact: testopia(a)bugs.koha-community.org I'm accruing many little issues. while running the code. I'll put the patches in, at least to document them. If the powers-that-be decide to fix in differently, all the same to me. -- You are receiving this mail because: You are watching all bug changes.

1 15

[Bug 18191] New: REST API: Add endpoint to list valid pickup locations
by bugzilla-daemon＠bugs.koha-community.org 18 Oct '21

18 Oct '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=18191 Bug ID: 18191 Summary: REST API: Add endpoint to list valid pickup locations 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: lari.taskula(a)jns.fi QA Contact: testopia(a)bugs.koha-community.org Bug 7534, Bug 7614 and Bug 18072 let us limit the choices of pickup location when placing a hold. Add a REST API endpoint that uses this functionality. GET /biblios/{biblionumber}/pickuplocations GET /item/{itemnumber}/pickuplocations Returns an array of library-objects that represent a set of libraries that can be used as pickup locations for hold of the given biblio/item. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 14

[Bug 15883] New: Upgrade jQuery from v1.7.2 in the staff client
by bugzilla-daemon＠bugs.koha-community.org 15 Oct '21

15 Oct '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15883 Bug ID: 15883 Summary: Upgrade jQuery from v1.7.2 in the staff client Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Templates Assignee: oleonard(a)myacpl.org Reporter: oleonard(a)myacpl.org QA Contact: testopia(a)bugs.koha-community.org Blocks: 14546 In order to upgrade Bootstrap in the staff client we first need to upgrade jQuery. After discussing it some in IRC (http://irc.koha-community.org/koha/2016-02-22#i_1791968) this is the plan I'm working on right now: An initial patch will start by adding the basis for upgrades: 1. Add a new version of doc-head-close.inc which includes new version of jQuery and jQueryUI. That include file will be named doc-head-close-jquery.1.12.0.inc to reflect the version of jQuery it uses. 2. Add the 1.12.0 version of jQuery, naming the file jquery-1.12.0.min.js 3. Add the latest version of jQueryUI, 1.11.4, naming the files jquery-ui-1.11.4.js and jquery-ui-1.11.4.min.css. Subsequent patches can take a page-by-page approach to the upgrade, dropping in the new include file and making any upgrades necessary to Javascript on that page. As compatibility issues are discovered, affected JS files can be re-created with updated file names to reflect the jQuery version, as in "basket-jquery-1.12.0.js" Disadvantages to this method: 1. It's possible some patches will have to touch both doc-head-close.inc and doc-head-close-jquery.1.12.0.inc. However that file changes fairly seldom. 2. git history getting lost between files. Can it be done so that the new include file keeps the history of doc-head-close.inc and doc-head-close.inc is created as if it is the new file? Eventually it could be removed. I would like to hear opinions and suggestions about this. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14546 [Bug 14546] Make staff client use Bootstrap -- You are receiving this mail because: You are watching all bug changes.

1 51

[Bug 18328] New: There is no history for article request
by bugzilla-daemon＠bugs.koha-community.org 11 Oct '21

11 Oct '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=18328 Bug ID: 18328 Summary: There is no history for article request Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: severine.queune(a)bulac.fr QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com Il would be useful if the "Cancelled requests" and "Completed requests" of articles request were kept in different tabs, just like it exists for acquisition suggestions. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 4