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

[Bug 20852] New: Make "All libraries" default organisation for article requests
by bugzilla-daemon＠bugs.koha-community.org 09 Jun '25

09 Jun '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20852 Bug ID: 20852 Summary: Make "All libraries" default organisation for article requests 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: katrin.fischer(a)bsz-bw.de QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com At the moment the pick-up location a user selects in the OPAC will decide which library the article request shows up for in the interface. The tabs are organized by pick-up location. - There is no label stating it's the pickup location in the staff interface. - The pick-up library is not necessarily the library, that will the article request. So for processing new article requests the workflow is not ideal, as the library always has to switch to 'all libraries' in order to see requests they possibly have to process. As Koha allows article requests to be set on record level, Koha doesn't know which libraries might be able to fill the article request. So it might be best to optionally allow setting to "all libraries" and also adapt the note on the dashboard accordingly. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 3

[Bug 20684] New: Don't allow article requests on lost and missing items
by bugzilla-daemon＠bugs.koha-community.org 09 Jun '25

09 Jun '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20684 Bug ID: 20684 Summary: Don't allow article requests on lost and missing items 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: katrin.fischer(a)bsz-bw.de QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com Article records on lost items or when all items are lost should not be possible. Maybe this could be changed into a general YAML based preference to rule out items by different criteria even (lost status, damaged status, collection). -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 2

[Bug 30829] New: Article requests: record level itemtype not taken into account when item exists
by bugzilla-daemon＠bugs.koha-community.org 09 Jun '25

09 Jun '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=30829 Bug ID: 30829 Summary: Article requests: record level itemtype not taken into account when item exists Change sponsored?: --- Product: Koha Version: 20.11 Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: katrin.fischer(a)bsz-bw.de QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com To test: - Create 2 records with a record level itype "article" - Add an item to one of those with the itype "reference" or similar - In the circulation conditions, allow article requests 'title only' for the itemtype article - Verify that the article request link is only shown for the first record without item, although it also matches the circulation rule In this case, the item is for a printed version of the article that is in storage and not supposed to be used. The library still wants people to use the article request feature to get the document. It seems strange with the record only option, that the item would overwrite the record level itemtype here. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 1

[Bug 31779] New: Article Request form shows all locations in pickup library menu
by bugzilla-daemon＠bugs.koha-community.org 09 Jun '25

09 Jun '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=31779 Bug ID: 31779 Summary: Article Request form shows all locations in pickup library menu Change sponsored?: --- Product: Koha Version: 22.05 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: ephetteplace(a)cca.edu QA Contact: testopia(a)bugs.koha-community.org To recreate: 1. have multiple locations/branches 2. set one to not be available as a pickup location 3. have an item where you can make article requests (e.g. a newspaper or journal) 4. go to the article request form for the item /cgi-bin/koha/opac-request-article.pl?biblionumber={{biblionumber}} 5. note the "pickup library" select menue at the bottom of the form Expected behavior: the location in step #2 will not be listed in the select menu because it is not an available pickup location. This is the case, for instance, on the holds form at /cgi-bin/koha/opac-reserve.pl?biblionumber={{biblionumber}}. Actual behavior: all libraries are listed. The template iterates over all branches `FOREACH b IN Branches.all` without discrimination. There's a question of whether article pickups and holds pickups should be treated the same, maybe there's some edge case where these are different, but for us and I would imagine the vast majority of libraries it doesn't make sense to offer a pickup location for articles when the branch itself doesn't process holds (usually means there are no circulation functions or staff at that location). I looked at the logic in koha-tmpl/opac-tmpl/bootstrap/en/modules/opac-reserve.tt to see if it could be easily copied over to the koha-tmpl/opac-tmpl/bootstrap/en/modules/opac-request-article.tt but it is not as straightforward as I'd expected. We will probably resort to OPACUserJS to work around this in the meantime. -- You are receiving this mail because: You are watching all bug changes.

1 3

[Bug 21060] New: Article requests: Null borrowernumber when borrower is deleted and keep request data for statistics
by bugzilla-daemon＠bugs.koha-community.org 09 Jun '25

09 Jun '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=21060 Bug ID: 21060 Summary: Article requests: Null borrowernumber when borrower is deleted and keep request data for statistics 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: katrin.fischer(a)bsz-bw.de QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com When a patron is deleted the article requests will also be deleted. This can leave holes in statistics. It would be nicer to cancel them and null the borrowernumber instead. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 1

[Bug 20973] New: Article requests: Can't tell which library filled an article request
by bugzilla-daemon＠bugs.koha-community.org 09 Jun '25

09 Jun '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20973 Bug ID: 20973 Summary: Article requests: Can't tell which library filled an article request 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: katrin.fischer(a)bsz-bw.de QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com, kyle(a)bywatersolutions.com In a multi branch setting any library might fill an article request, but at the moment only the pick-up library is stored. There is no way to tell which library actually filled the request which is important for statistics. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 3

[Bug 28767] New: AddReturn should also look at current article requests
by bugzilla-daemon＠bugs.koha-community.org 09 Jun '25

09 Jun '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28767 Bug ID: 28767 Summary: AddReturn should also look at current article requests 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: m.de.rooy(a)rijksmuseum.nl QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com The article requests feature has unfortunately not been integrated into Koha's Circulation module. This is just a small step in bridging the gap. Apart from looking at reserves/holds, AddReturn should also look at older open article requests (prioritizing them over newer holds). This should be preference controlled in order to keep existing behavior. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 3

[Bug 33742] New: Add permission to circumvent HidePatronName syspref
by bugzilla-daemon＠bugs.koha-community.org 06 Jun '25

06 Jun '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33742 Bug ID: 33742 Summary: Add permission to circumvent HidePatronName syspref Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Staff interface Assignee: koha-bugs(a)lists.koha-community.org Reporter: andrewfh(a)dubcolib.org QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com It would be helpful to have a permission with which an individual user could be set to see patron names throughout the staff interface regardless of the HidePatronName value. We have a small number of volunteers with very limited Koha access -- essentially just the "catalogue" permission. If we turned HidePatronName to Show, the volunteers would be able to see who a given item is checked out to. But we would like staff to be able to see that information. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 6

[Bug 29974] New: Changing status of held item to Damaged can result in inaccurate hold status
by bugzilla-daemon＠bugs.koha-community.org 06 Jun '25

06 Jun '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=29974 Bug ID: 29974 Summary: Changing status of held item to Damaged can result in inaccurate hold status Change sponsored?: --- Product: Koha Version: 21.05 Hardware: All OS: All Status: NEW Severity: trivial Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: sbrown(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com With AllowHoldsOnDamagedItems set to "don't allow", if an undamaged item is waiting on hold for a patron, has its Damaged status set while waiting, and then is checked out to the patron, Koha thinks the item is simultaneously still held and checked out. To recreate: -Place a hold on an undamaged item -Trigger the hold -Once the item is waiting for the patron, change its status to Damaged -Check the item out to that patron In the bib, the item now shows as both waiting and checked out in the holdings table and in the Holds tab as waiting. In the patron's record, it shows as checked out and waiting. It also still shows in 'Holds awaiting pickup'. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 10

[Bug 21697] New: Free-floating subdivision cannot be manage correctly in Koha
by bugzilla-daemon＠bugs.koha-community.org 06 Jun '25

06 Jun '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=21697 Bug ID: 21697 Summary: Free-floating subdivision cannot be manage correctly in Koha Change sponsored?: --- Product: Koha Version: 18.05 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: MARC Authority data support Assignee: koha-bugs(a)lists.koha-community.org Reporter: hector.hecaxmmx(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org Koha doesn't have right authority frameworks to deal with free-floating subdivisions records 180, 181, 182, and, 185. These fields needs their own frameworks to work properly an to be searchable headings. When you prepare this kind of records in ISO2709 file and export them to Koha, Koha treat well as free-floating subdivisions but there aren't frameworks to deal with. So the heading are stored but not searchable. You can see this in module C4::AuthoritiesMarc lines 350-367 sub GuessAuthTypeCode { my ($record, $heading_fields) = @_; return unless defined $record; $heading_fields //= { "MARC21"=>{ '100'=>{authtypecode=>'PERSO_NAME'}, '110'=>{authtypecode=>'CORPO_NAME'}, '111'=>{authtypecode=>'MEETI_NAME'}, '130'=>{authtypecode=>'UNIF_TITLE'}, '148'=>{authtypecode=>'CHRON_TERM'}, '150'=>{authtypecode=>'TOPIC_TERM'}, '151'=>{authtypecode=>'GEOGR_NAME'}, '155'=>{authtypecode=>'GENRE/FORM'}, '180'=>{authtypecode=>'GEN_SUBDIV'}, '181'=>{authtypecode=>'GEO_SUBDIV'}, '182'=>{authtypecode=>'CHRON_SUBD'}, '185'=>{authtypecode=>'FORM_SUBD'}, }, NOTE: These records are not usable in biblio records but serves to librarians to take decision when creating complex-headings. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 6