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

[Bug 28846] New: MarcRecordFromNewSuggestion needs mapping to biblioitems.itemtype
by bugzilla-daemon＠bugs.koha-community.org 14 Aug '26

14 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28846 Bug ID: 28846 Summary: MarcRecordFromNewSuggestion needs mapping to biblioitems.itemtype 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: fridolin.somers(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org In C4::Suggestions, MarcRecordFromNewSuggestion uses mapping to biblioitems.itemtype : https://git.koha-community.org/Koha-community/Koha/src/commit/e9428f662fe2e… But this Koha to MARC mapping may not exists when itemtype is on item level. Same for biblio.autor, even if unlikely. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 16

[Bug 35200] New: Patron attributes should be translatable
by bugzilla-daemon＠bugs.koha-community.org 13 Aug '26

13 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35200 Bug ID: 35200 Summary: Patron attributes should be translatable Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: I18N/L10N 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: frederic(a)tamil.fr I ran into this problem with a library that needed a lot of patron attributes, and they use self-registration. Their OPAC is in fr-CA, en, and es-ES. I created the patron attributes with labels in french. But then I had to write JQuery to translate them in en and es-ES. This is a sample of the js (I'm not a developer, so it might not be great, but it seems to work) $("html[lang='en'] body#opac-patron-registration a[name='patron-attr-start-1_NOM'] + li label").text("Baby's surname:"); $("html[lang='en'] body#opac-patron-registration a[name='patron-attr-start-2_DOSSIER'] + li label").text("Baby's file number:"); $("html[lang='es-ES'] body#opac-patron-registration a[name='patron-attr-start-1_NOM'] + li label").text("Apellido del bebe:"); $("html[lang='es-ES'] body#opac-patron-registration a[name='patron-attr-start-2_DOSSIER'] + li label").text("Número de expediente del bebé:"); I wonder if it would be possible to use the same process as translating the itemtypes (entry in localization table). -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 4

[Bug 33364] New: Stop Holds to Pull report showing items that have been allocated to a recall
by bugzilla-daemon＠bugs.koha-community.org 13 Aug '26

13 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33364 Bug ID: 33364 Summary: Stop Holds to Pull report showing items that have been allocated to a recall Change sponsored?: --- Product: Koha Version: 22.11 Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Hold requests 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 The Holds to Pull report shows an item with a hold if the item is available on the shelf, ready to pull and allocate to the hold. The Holds to Pull should NOT show an item with a hold if that item has already been allocated to a recall (i.e. the recalled item is awaiting pickup and or in transit for a patron). To reproduce: 1. Enable UseRecalls and set the recalls-related circulation rules 2. Check out an item to Patron A 3. Place a hold on the item for Patron B 4. Log into the OPAC as Patron C and search for the item. Place a recall on the item. 5. Go back to the staff interface. Go to Circulation -> Holds to pull 6. Confirm the item shows in the Holds to pull table, with the hold for Patron B 7. Check in the item and confirm the recall as waiting 8. Go back to the Holds to pull page. You could manually regenerate the page but running the cronjob in the terminal misc/cronjobs/holds/build_holds_queue.pl 9. Notice that even though the item is allocated for a recall, the hold is showing. It should not be showing in this page. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 48

[Bug 34962] New: Add a system messages feature to Koha to report issues and failures in a more visible way
by bugzilla-daemon＠bugs.koha-community.org 13 Aug '26

13 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=34962 Bug ID: 34962 Summary: Add a system messages feature to Koha to report issues and failures in a more visible way Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: koha-bugs(a)lists.koha-community.org Reporter: kyle(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org Many web projects have a "system messages" area to report cron failures and things like that. These messages are often dismissable. I think it would be great to have a "system messages" table that we could insert things into to make staff aware that something has failed. What I'm imagining is something like wrapping cronjob code in a try/catch and reporting cronjob failures. This would dovetail with action logs. Action logs lot you got searching for issues. This would put the issue right in front of you and would be trigger by actual failures. It could be used to report records with malformed MARC. It could be used to report items that are missing a required field that Koha assumes exists to function, and so on. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 11

[Bug 25267] New: OPAC Browse Shelf feature is not responsive
by bugzilla-daemon＠bugs.koha-community.org 13 Aug '26

13 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25267 Bug ID: 25267 Summary: OPAC Browse Shelf feature is not responsive Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: lucas(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org On the OPAC the browse shelf feature is not responsive. To recreate: 1. Turn on OPACShelfBrowser. 2. If youre using test data you will have to give some items call numbers. I did: update items set itemcallnumber = 'acallnumber'; 3. It will also be best if you add some cover images. 4. Go to an item detail page and Browse Shelf. 5. The feature looks good until the viewport is about 1700px or less. -- You are receiving this mail because: You are watching all bug changes.

1 64

[Bug 34772] New: Curbside pickup - Assign multiple pickups to a single patron
by bugzilla-daemon＠bugs.koha-community.org 13 Aug '26

13 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=34772 Bug ID: 34772 Summary: Curbside pickup - Assign multiple pickups to a single patron 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: fabriciomolina(a)theke.io QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com Enable a checkbox in the surbside pickup creation so that the administrator can assign multiple pickups to a single patron. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 6

[Bug 27427] New: Update the way form validation errors are displayed
by bugzilla-daemon＠bugs.koha-community.org 13 Aug '26

13 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=27427 Bug ID: 27427 Summary: Update the way form validation errors are displayed Change sponsored?: --- Product: Koha Version: unspecified Hardware: All 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 Blocks: 27289 I would like to update the way form validation errors are shown by the jQuery validation plugin. The changes depend on the plugin's event handler for "valid" and "invalid" inputs. Upon being checked by the plugin, a valid input will have any following <span class="required"> styled green and with a check mark to indicate validity. An invalid input will have any following <span class="required"> hidden and the jQuery validation error shown instead. https://zivotdesign.com/n/index.php/s/6WrBe3G8mzoLXsN Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=27289 [Bug 27289] Template tweaks for point of sale page -- You are receiving this mail because: You are watching all bug changes.

1 12

[Bug 28527] New: Transfers that are cancelled whilst in transit should still appear as 'in transit' until they are received
by bugzilla-daemon＠bugs.koha-community.org 13 Aug '26

13 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28527 Bug ID: 28527 Summary: Transfers that are cancelled whilst in transit should still appear as 'in transit' until they are received Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Staff Client Assignee: koha-bugs(a)lists.koha-community.org Reporter: martin.renvoize(a)ptfs-europe.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com If a transfer is cancelled whilst it is in transit (datesent set, but datearrived not) then we should still return it as in transit. Bug 27993 added a condition to the 'in_transit' boolean which should be reverted. We should also update the get_transfer (and get_transfers) methods to catch such cases and return those still active transfers and deal with them appropriately at check-in. (i.e. invoke the reverse transfer or pick the next transfer from the queue and notify the librarian of what subsequent actions they should take). -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 40

[Bug 33302] New: Placing item level holds in OPAC allows to pick forbidden pick-up locations, but then places no hold
by bugzilla-daemon＠bugs.koha-community.org 13 Aug '26

13 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33302 Bug ID: 33302 Summary: Placing item level holds in OPAC allows to pick forbidden pick-up locations, but then places no hold Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Hold requests 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(a)bywatersolutions.com, tomascohen(a)gmail.com A bit much to put in the description, but the problem is about item level holds failing to be placed silently in the OPAC. To test: With the sample data in ktd or sandboxes: 1) Enforce library transfer limits (UseBranchTransferLimits) on itemtypes (BranchTransferLimitsType). 2) In administration > branch transfer rules: disallow transfer from Midway to any other library for item type BK (Books) 3) Search for a record with at least one item in Midway in staff 4) Try to place an item level hold on a Midway item. I used: Intermediate Perl, biblionumber 126 For the Midway item, only Midway will show as possible pickup-location This is correct. 5) Switch to the OPAC 6) Try to place an item level hold there on the Midway item, for pick-up at Centerville. 7) Place a hold on the Midway item for pick-up at any non-Midway location 8) Verify the page saves without error, but the hold was not placed. - The basic issue here is that item specific pickup locations != record-specific pickup locations. In the staff interface we have a separate pull down "allowed pick-up locations" for each item in the list. I think we should implement the same in the OPAC to help the users see what is allowed and what not. And deacticate the pull down on top when an item is selected. But: At least we should give proper feedback that a hold could not be placed because of the pick-up location instead of failing silently! -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 24

[Bug 33179] New: Allow for libraries to automatically suppress a bibliographic record from OPAC if no items are attached
by bugzilla-daemon＠bugs.koha-community.org 13 Aug '26

13 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33179 Bug ID: 33179 Summary: Allow for libraries to automatically suppress a bibliographic record from OPAC if no items are attached Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Cataloging Assignee: koha-bugs(a)lists.koha-community.org Reporter: kelly(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl It would be nice for Koha to allow libraries to automatically suppress a bibliographic record from OPAC if no items are attached. Currently, the library would need to manually add a 942$n = 1 to suppress records. But if the record has no items and can automatically be suppressed until items are attached, this would be a nice efficient workflow. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 7