May 2023 - Koha-bugs - lists.koha-community.org

[Bug 30979] New: Add ability for opac users to checkout to themselves
by bugzilla-daemon＠bugs.koha-community.org 30 May '25

30 May '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=30979 Bug ID: 30979 Summary: Add ability for opac users to checkout to themselves Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: martin.renvoize(a)ptfs-europe.com QA Contact: testopia(a)bugs.koha-community.org In some trusted environments libraries would like their users to self-issue without having to use the SCO or SIP checkouts. i.e. once logged in a user should have the ability to check out to themselves much like they already have the option to renew and place holds etc. -- You are receiving this mail because: You are watching all bug changes.

1 187

[Bug 33711] New: Refine the token passing mechanisms introduced in bug 23336
by bugzilla-daemon＠bugs.koha-community.org 30 May '25

30 May '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33711 Bug ID: 33711 Summary: Refine the token passing mechanisms introduced in bug 23336 Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: REST API Assignee: koha-bugs(a)lists.koha-community.org Reporter: martin.renvoize(a)ptfs-europe.com CC: koha-bugs(a)lists.koha-community.org, tomascohen(a)gmail.com Depends on: 23336 Bug 23336 introduces an API workflow for checkouts by adding two endpoints.. one for availability that creates a token for confirmations that can then be used by the checkouts endpoint to verify that availability has been checked. Whilst I think the availability endpoint is worthwhile in it's own right, I think we could also send back the token in the 409 pre-condition failed response of the checkouts endpoint so one could use that single endpoint for double duty in the right circumstances. I also think we could work on how the confirmation token is sent to the endpoint.. it's currently a simple query param but may lend itself to being part of the x-koha-overrides header or another header? Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23336 [Bug 23336] Add an API endpoint for issuing an item to a patron -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes. You are on the CC list for the bug.

1 3

[Bug 33709] New: Add override options to checkouts
by bugzilla-daemon＠bugs.koha-community.org 30 May '25

30 May '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33709 Bug ID: 33709 Summary: Add override options to checkouts Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: REST API Assignee: koha-bugs(a)lists.koha-community.org Reporter: martin.renvoize(a)ptfs-europe.com CC: tomascohen(a)gmail.com Depends on: 23336 I stripped out the local overrides when creating a checkouts POST route.. we should add them back in using the accepted x-koha-overrides method. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23336 [Bug 23336] Add an API endpoint for issuing an item to a patron -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 7

[Bug 30281] New: Schedule batch patron deletion and anonymization
by bugzilla-daemon＠bugs.koha-community.org 29 May '25

29 May '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=30281 Bug ID: 30281 Summary: Schedule batch patron deletion and anonymization Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Tools Assignee: koha-bugs(a)lists.koha-community.org Reporter: cbrannon(a)cdalibrary.org QA Contact: testopia(a)bugs.koha-community.org Would love to see someone incorporate reoccurring scheduling on this page that didn't require us to setup a cron job on the backend. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 5

[Bug 27935] New: Allow item search fields to be defined from database fields rather than MARC tags
by bugzilla-daemon＠bugs.koha-community.org 29 May '25

29 May '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=27935 Bug ID: 27935 Summary: Allow item search fields to be defined from database fields rather than MARC tags Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Searching Assignee: koha-bugs(a)lists.koha-community.org Reporter: andrew(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org The item search fields interface allows one to specify MARC tags to be used as custom search fields. It'd be handy to also have the option of specifying database fields, for the various bib/item values that don't get stored in the MARC. This would be handy for folks who don't or can't use reports and therefore rely on item search. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 2

[Bug 32967] New: Recalls notices are using the wrong database columns
by bugzilla-daemon＠bugs.koha-community.org 29 May '25

29 May '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32967 Bug ID: 32967 Summary: Recalls notices are using the wrong database columns Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Tools Assignee: koha-bugs(a)lists.koha-community.org Reporter: aleisha(a)catalyst.net.nz QA Contact: testopia(a)bugs.koha-community.org The recalls table column names were changed before they were upstreamed but this change wasn't carried over to the notices. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 15

[Bug 33220] New: Recalls to pull should not show in transit or allocated items
by bugzilla-daemon＠bugs.koha-community.org 29 May '25

29 May '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33220 Bug ID: 33220 Summary: Recalls to pull should not show in transit or allocated items Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: aleisha(a)catalyst.net.nz QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com Recalls to pull report does not show accurate information. Recalled items that are in transit should not show on the recalls to pull page, as the item has been allocated already, and it's not on the shelf ready to pull. To reproduce: 1. Check out Item A to Patron A. Item A should be the only item on Biblio A (pick a record with only one item, or create a record with one item). 2. Log into the OPAC as Patron B 3. Place a recall on Item A for Patron B. Change the pickup library so it isn't your default library 4. Log back into the staff interface 5. Check in Item A, make sure you're not logged into the selected pickup library so we trigger a transfer. 6. Confirm the recall and transfer. 7. Go to Circulation -> Recalls to pull. Notice the recall shows here, even though it is not ready to pull. Also, for records that have multiple recalls, the information may show wrongly on recalls to pull. To reproduce: 1. Cancel any recalls on Item A/Biblio A. 2. Check out Item A to Patron A. Item A should be the only item on Biblio A (pick a record with only one item, or create a record with one item). 2. Log into the OPAC as Patron B. 3. Place a recall on Item A for Patron B. 4. Log into the OPAC as Patron C. 5. Place a recall on Item A for Patron C. Item A should now be checked out to Patron A, with two recalls on it for Patrons B and C. 6. Log back into the staff interface. 7. Check in Item A. Confirm the recall as waiting for Patron B. 8. Go to Circulation -> Recalls to pull. Notice the recall for Patron C shows here, even though the one item that could fill this recall has already been allocated to Patron B. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 13

[Bug 32268] New: t/db_dependent/XSLT.t is failing randomly
by bugzilla-daemon＠bugs.koha-community.org 29 May '25

29 May '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32268 Bug ID: 32268 Summary: t/db_dependent/XSLT.t is failing randomly Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Test Suite Assignee: chris(a)bigballofwax.co.nz Reporter: jonathan.druart+koha(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org Depends on: 19532 Blocks: 25551 Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19532 [Bug 19532] Recalls for Koha https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25551 [Bug 25551] [OMNIBUS] Some tests are failing randomly -- You are receiving this mail because: You are watching all bug changes.

1 11

[Bug 32445] New: Status display of 'not for loan' items is broken in OPAC/staff
by bugzilla-daemon＠bugs.koha-community.org 29 May '25

29 May '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32445 Bug ID: 32445 Summary: Status display of 'not for loan' items is broken in OPAC/staff Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: major 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 This is a display issue, but marking as major since it affects a basic functionality in the OPAC: 1) Edit any item, item type should be for loan, so not set to reference. 2) Set Not for loan status to "not for loan". 3) Go to the staff detail page: 4) Verify it displays as: Not for loan (Not For Loan) Available The available should not be there! 5) Go to the OPAC detail page: 6) Verifiy the status displays as: Available This should display the not for loan status! -- You are receiving this mail because: You are watching all bug changes.

1 67

[Bug 31147] New: Recalls due date to the minute rather than 23:59
by bugzilla-daemon＠bugs.koha-community.org 29 May '25

29 May '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=31147 Bug ID: 31147 Summary: Recalls due date to the minute rather than 23:59 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: caroline.cyr-la-rose(a)inlibro.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com I don't know if this is intended behaviour or a bug. When placing a recall, the new due date is exactly now + recall due date interval. Let's say my recall due date interval is 7 and an item is due 2022-08-31 23:59:00. If I place my recall today (2022-07-12) at 16:31:14, the new due date will be 2022-07-19 16:31:14. Like I said, I'm not sure if this is the intended behaviour, but in my very unknowledgable opinion, I find it a bit extreme to ask someone out of the blue to return an item by a certain time (to the second). To test: 1) Turn on recalls 1.1) In Administration > Global system preferences, enable UseRecalls 1.2) Add recalls permissions in your circulation rules 2) Find a record with a checked out item; check the due date for that checked out item, e.g. SELECT date_due FROM issues WHERE itemnumber = XXXX; --> It should be YYYY-MM-DD 23:59:00 3) In the OPAC, log in as a patron 4) Find the same record and place a recall 5) Check the new due date --> It should be today + the number of days you put in recall due date interval in step 1.2 at the exact time you placed the recall -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 21