October 2016 - Koha-bugs - lists.koha-community.org

[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 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 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 16825] New: Add API route for getting an item
by bugzilla-daemon＠bugs.koha-community.org 06 Oct '21

06 Oct '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=16825 Bug ID: 16825 Summary: Add API route for getting an item 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: larit(a)student.uef.fi QA Contact: testopia(a)bugs.koha-community.org Add API route for getting an item GET /api/v1/items/{itemnumber} Gets one Item -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 93

[Bug 17336] New: api_secret_passphrase missing in packages setup
by bugzilla-daemon＠bugs.koha-community.org 20 Sep '21

20 Sep '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17336 Bug ID: 17336 Summary: api_secret_passphrase missing in packages setup Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: major Priority: P5 - low Component: Web services Assignee: koha-bugs(a)lists.koha-community.org Reporter: tomascohen(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org Bug 13799 introduced the api_secret_passphrase on source installs, but missed to do so on packages. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 16

[Bug 17335] New: waitingreserves.pl cancel button needs simplification
by bugzilla-daemon＠bugs.koha-community.org 11 Aug '21

11 Aug '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17335 Bug ID: 17335 Summary: waitingreserves.pl cancel button needs simplification 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: cbrannon(a)cdalibrary.org QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com I would suggest that the Cancel Hold button is overly complicated and should be simplified. At the very least, this should be an option. Currently (3.22.8) it doesn't seem to matter if there is another hold or if the item is a local item or going somewhere. Its behavior doesn't differ from one button to the next. Aside from that, if this function were to be fixed, say, bug 17010, it really doesn't matter (at least to some libraries) what happens next. The behavior following the press of the button should be self evident. One could also assume that getting information as to what happens next to each hold and customizing the button is using processing time to build the page. Time which is a waste. I think that the buttons next to all the holds should just simply read "Cancel hold". If it is an issue, this should be a preference, that would eliminate any background processes building the buttons, and give a simple Cancel hold label. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 7

[Bug 15969] New: Allow use of Template Toolkit syntax for Phone Notices
by bugzilla-daemon＠bugs.koha-community.org 09 Jul '21

09 Jul '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15969 Bug ID: 15969 Summary: Allow use of Template Toolkit syntax for Phone Notices 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: kyle(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org By allowing the use of Template Toolkit for generating the outgoing Talking Tech CSV files, we can give libaries more control over the data they send to Itiva. This enhancement would also make it possible to use the script for other services since the output is no longer fixed to a single format. -- You are receiving this mail because: You are watching all bug changes.

1 75

[Bug 15788] New: Split borrowers permission into create/edit
by bugzilla-daemon＠bugs.koha-community.org 02 Jul '21

02 Jul '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15788 Bug ID: 15788 Summary: Split borrowers permission into create/edit Change sponsored?: Seeking cosponsors Product: Koha Version: master Hardware: All URL: http://devs.bywatersolutions.com/projects/patron-edit- permission/ OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Patrons Assignee: koha-bugs(a)lists.koha-community.org Reporter: nengard(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com Goal : Add ability to control if a staff user can create new patrons vs editing existing patrons Work to be done: 1) Add new borrowers sub-permission ‘modify’ 2) Add new borrowers sub-permission ‘create’ 3) Implement new permissions for patron editor/creator Looking for sponsors here: http://devs.bywatersolutions.com/projects/patron-edit-permission/ -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 40