January 2020 - Koha-bugs - lists.koha-community.org

[Bug 16457] New: Remove the use of "onclick" from the patron entry form
by bugzilla-daemon＠bugs.koha-community.org 11 Jun '26

11 Jun '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=16457 Bug ID: 16457 Summary: Remove the use of "onclick" from the patron entry form Change sponsored?: --- Product: Koha Version: master Hardware: All URL: /cgi-bin/koha/members/memberentry.pl OS: All Status: ASSIGNED Severity: enhancement Priority: P5 - low Component: Templates Assignee: oleonard(a)myacpl.org Reporter: oleonard(a)myacpl.org QA Contact: testopia(a)bugs.koha-community.org CC: testopia(a)bugs.koha-community.org Depends on: 13041, 16386, 16450 There are several instances of "onclick" in memberentrygen.tt. It should be rewritten so that JS functionality can be separate from the markup. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=13041 [Bug 13041] Can't add user as manager of basket if name includes a single quote https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=16386 [Bug 16386] Replace the use of "onclick" from patron card creator templates https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=16450 [Bug 16450] Remove the use of "onclick" from guarantor search template -- You are receiving this mail because: You are watching all bug changes.

1 19

[Bug 20512] New: Add a second sort possibility in a public list
by bugzilla-daemon＠bugs.koha-community.org 11 Jun '26

11 Jun '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20512 Bug ID: 20512 Summary: Add a second sort possibility in a public list Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Lists Assignee: koha-bugs(a)lists.koha-community.org Reporter: patrick.robitaille(a)collecto.ca QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl Hi, when you sort a public list by call number at the intranet, the documents how has a Lc and a DDC code are placed at the top of the list. to recreate this problem 1) creat a public list with records who have two classifications. 2) Add somes records with only one classification and who would rank before works with two classifications. 2) Sort thi new list by call number. You will notice that the records with tow classificaton codes are at the top of the list It would be greate if we can add the possibility too do a second sort by classification code. Thanks, Patrick. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 3

[Bug 21572] New: Allow checkout an item with reserve that is not yet in waiting state
by bugzilla-daemon＠bugs.koha-community.org 10 Jun '26

10 Jun '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=21572 Bug ID: 21572 Summary: Allow checkout an item with reserve that is not yet in waiting state 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: joonas.kylmala(a)helsinki.fi QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com Currently if a librarian checkouts an item to a patron that is in the "Reserved" state the librarian will get a prompt saying "Item Whinney pooh / (1111111111 has been on hold for Joe (1111111111) at My Library since 15.10.2018". If there is little staff the holds might pile up and then patrons who actually went to the library cannot checkout those items. Some libraries prefer to give the first to the patrons who went actually to the physical library building instead of just reserved it online. Koha actually used to work like this with the SIP server before commit "Bug 15438 - Checking out an on-hold item sends holder's borrowernumber in AF (screen message) field." -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 81

[Bug 17272] New: Override permissions
by bugzilla-daemon＠bugs.koha-community.org 10 Jun '26

10 Jun '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17272 Bug ID: 17272 Summary: Override permissions 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: cbrannon(a)cdalibrary.org QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com There should be an Override permission in the user's permissions, with a child permission for each type of override. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 7

[Bug 17858] New: Omnibus: Move staff client JavaScript to the footer
by bugzilla-daemon＠bugs.koha-community.org 10 Jun '26

10 Jun '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17858 Bug ID: 17858 Summary: Omnibus: Move staff client JavaScript to the footer Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Templates Assignee: oleonard(a)myacpl.org Reporter: oleonard(a)myacpl.org QA Contact: testopia(a)bugs.koha-community.org Depends on: 17418 In order to conform to best practices for performance staff client template javascript should be in the footer instead of the header. This omnibus bug will collect reports which modify subsets of the staff client templates. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17418 [Bug 17418] Move staff client home page JavaScript to the footer -- You are receiving this mail because: You are watching all bug changes.

1 121

[Bug 18861] New: branch_transfer_limits needs keys
by bugzilla-daemon＠bugs.koha-community.org 10 Jun '26

10 Jun '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=18861 Bug ID: 18861 Summary: branch_transfer_limits needs keys Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: System Administration Assignee: koha-bugs(a)lists.koha-community.org Reporter: fridolin.somers(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com The branch transfers limits are edited in : /cgi-bin/koha/admin/branch_transfer_limits.pl This page calls a loop on IsBranchTransferAllowed with all destination branches and codes (ccodes or itemtypes). This can takes a huge time because table branch_transfer_limits has no keys. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 15

[Bug 23874] New: Advanced Editor is not loaded over HTTPS
by bugzilla-daemon＠bugs.koha-community.org 04 Jun '26

04 Jun '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23874 Bug ID: 23874 Summary: Advanced Editor is not loaded over HTTPS Change sponsored?: --- Product: Koha Version: 19.05 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Cataloging Assignee: koha-bugs(a)lists.koha-community.org Reporter: fraktik(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl Symptoms: Loading, please wait... Editor of record is visually loaded in background, but over it is big endless running circle with announcement: "Loading, please wait... Source of problem: The script is by default blocked by browsers because there is some hardlink to HTTP content. Another details: - This is related both to 18.05 and 19.05, Firefox and Chrome, Win10 and Ubuntu, and it's behaving practically same. - We have in general disabled (forwarded) all unsecured traffic to https at our nginx rproxy server. Console output: Blocked loading mixed active content “http://demo.koha.cz/cgi-bin/koha/svc/cataloguing/framework?callback=define” editor.pl The resource from “https://demo.koha.cz/cgi-bin/koha/svc/cataloguing/framework?frameworkcode=&callback=define” was blocked due to MIME type (“text/html”) mismatch (X-Content-Type-Options: nosniff). editor.pl <script> source URI is not allowed in this document: “https://demo.koha.cz/cgi-bin/koha/svc/cataloguing/framework?frameworkcode=&callback=define”. editor.pl:1:1 Error: Script error for: /cgi-bin/koha/svc/cataloguing/framework?frameworkcode=&callback=define http://requirejs.org/docs/errors.html#scripterror -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 17

[Bug 24073] New: Allow suggestion management page to default to all libraries
by bugzilla-daemon＠bugs.koha-community.org 04 Jun '26

04 Jun '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=24073 Bug ID: 24073 Summary: Allow suggestion management page to default to all libraries 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: andrew(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org When looking at purchase suggestions on suggestion.pl, the default behavior is to show only suggestions for the branch one is logged in at. This can result in overlooked suggestions, especially for libraries that have more than once branch but process all suggestions at a single location. It would be good to have the option of making this page default to showing suggestions for all libraries. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 13

[Bug 24414] New: Can't add/delete funds with only budget_add_del permission
by bugzilla-daemon＠bugs.koha-community.org 03 Jun '26

03 Jun '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=24414 Bug ID: 24414 Summary: Can't add/delete funds with only budget_add_del permission 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: caroline.cyr-la-rose(a)inlibro.com QA Contact: testopia(a)bugs.koha-community.org This is very minor, but I was trying out all the permissions to better document them in the manual and I found something weird. There are several permissions granting access to funds. - budget_add_del described as 'Add and delete funds (but can't modify funds)' - budget_manage described as 'Manage funds' - budget_manage_all described as 'Manage all funds' - budget_modify described as 'Modify funds (can't create lines but can modify existing ones)' If I only have budget_add_del, I can't create or delete funds. I have to have budget_manage to access the funds administration page. Which is ok, I can simply add a note in the manual that budget_add_del requires budget_manage. If I have budget_add_del and budget_manage, I have access to the funds administration page, but not the 'New fund' button nor the 'Actions' button to delete an existing fund. So in reality, I can't add nor delete funds... If I have budget_manage and budget_modify (but not budget_add_del), I can't add new funds I can't edit existing ones, but I can delete them. To test : 1) Create a patron and give them the catalogue permission and the budget_add_del permission 2) Log in with this patron (I use a private window to be able to go back and change their permissions later without logging out again) 3) Go to the Acquisitions page 4) Notice you can see the budget, but you can't click on the fund code and you don't have the 'Funds' link in the left menu 5) Go back to edit the user's permissions and grant them budget_manage; save 6) Go back to the Acquisition page with the limited patron (refresh if needed) 7) Notice that you can now click on the fund code and you have a 'Funds' link on the left side of the screen 8) Click on the fund code 9) Click on 'New' and choose 'Add fund for xx'; add the new fund 10) Notice there is no 'Actions' button from which you can delete this fund 11) Go back to edit the user's permissions and remove the budget_add_del permission and add the budget_modify; save 12) Go back to the Acquisition page with the limited patron (refresh if needed) 13) Click on the 'Actions' button and choose 'Edit'; the page refreshes, but nothing happens 14) Click on the 'Actions' button and choose 'Delete' and confirm; the fund is deleted I have trouble imagining a situation where we would want staff to be able to add and delete funds but not modify them, so that's why I said I think this is minor. I think in most cases, the staff member will have at least all three (budget_add_del, budget_manage and budget_modify). But I still wanted to record the weirdness somewhere. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 4

[Bug 19958] New: Allow the system preference AutoMemberNum to include a combination of numbers and letters when creating a new barcode
by bugzilla-daemon＠bugs.koha-community.org 02 Jun '26

02 Jun '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19958 Bug ID: 19958 Summary: Allow the system preference AutoMemberNum to include a combination of numbers and letters when creating a new barcode Change sponsored?: --- Product: Koha Version: 17.05 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Patrons Assignee: koha-bugs(a)lists.koha-community.org Reporter: kelly(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com Currently the system preference "automembernum" only allows for the patron's barcode to default the card number field on the patron addition screen to the next available card number (for example, if the largest currently used card number is 26345000012941, then this field will default to 26345000012942). It would be nice for the library to choose the format of the barcode (for example : system preference autobarcode). Then a library could choose to include letters and numbers to their patron's barcode instead of just numbers. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 6