September 2024 - Koha-bugs - lists.koha-community.org

[Bug 31610] New: When creating a guarantee, patron messaging preferences should be copied to this account from the category
by bugzilla-daemon＠bugs.koha-community.org 07 Aug '25

07 Aug '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=31610 Bug ID: 31610 Summary: When creating a guarantee, patron messaging preferences should be copied to this account from the category Change sponsored?: --- Product: Koha Version: unspecified 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 When creating a guarantee, patron messaging preferences should be copied to this account from the category. Steps: Have a guarantor. Create a guarantee. Koha will use the CHILD patron category to assign this guarantee, but will not copy over the message preferences from this CHILD patron category. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 20

[Bug 25936] New: Notify users if their password has changed
by bugzilla-daemon＠bugs.koha-community.org 06 Aug '25

06 Aug '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25936 Bug ID: 25936 Summary: Notify users if their password has changed Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Authentication Assignee: koha-bugs(a)lists.koha-community.org Reporter: dcook(a)prosentient.com.au QA Contact: testopia(a)bugs.koha-community.org CC: dpavlin(a)rot13.org We should email/SMS users if their password has changed. We shouldn't include any information about the old or new password, but just alert them that it has been changed. This is useful in the event that someone has compromised an account and changed the password. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 60

[Bug 36990] New: Move MarcEdit tutorials out of the manual, into the wiki
by bugzilla-daemon＠bugs.koha-community.org 06 Aug '25

06 Aug '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36990 Bug ID: 36990 Summary: Move MarcEdit tutorials out of the manual, into the wiki Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Documentation Assignee: koha-bugs(a)lists.koha-community.org Reporter: caroline.cyr-la-rose(a)inlibro.com QA Contact: testopia(a)bugs.koha-community.org In one of the docs meeting (april 2024?), we decided that the Koha manual should be used to describe how to use Koha, and not how to use other software. Integration examples should be in the Koha wiki. As the MarcEdit section at the end of the cataloging chapter (https://koha-community.org/manual/latest/en/html/cataloging.html#handling-o…) not only describes how to use another software, it is also possible wildly out of date >This tutorial was written with MARCEdit version 5.2.3769.41641 on Windows XP, instructions may be different if your version or operating system is different. MarcEdit is now at version 7 and Windows is... 11? (sorry, I don't use windows or follow its development) This should be moved to the wiki as an example of MarcEdit use with Koha. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 7

[Bug 26869] New: Create items across batch of bibs
by bugzilla-daemon＠bugs.koha-community.org 06 Aug '25

06 Aug '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26869 Bug ID: 26869 Summary: Create items across batch of bibs Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Cataloging Assignee: koha-bugs(a)lists.koha-community.org Reporter: andrew(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl Say I have a couple thousand records for eBooks. I imported them without adding items, but decided later that I'd like to have items to ease searching. I'd love to be able to add those to my bibs in a batch without exporting and re-importing them. I'm imagining an interface like additem.pl except items I define would be created across all the bibs I've indicated. Ideally, there'd be some mechanism for values like itype and call number to choose whether you want Koha to apply a static value for all the items or derive specific values from the bibs. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 87

[Bug 36431] New: SIP2: Checkin does not show difference between WasTransfered and NeedsTransfer
by bugzilla-daemon＠bugs.koha-community.org 06 Aug '25

06 Aug '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36431 Bug ID: 36431 Summary: SIP2: Checkin does not show difference between WasTransfered and NeedsTransfer Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: SIP2 Assignee: koha-bugs(a)lists.koha-community.org Reporter: m.de.rooy(a)rijksmuseum.nl QA Contact: testopia(a)bugs.koha-community.org If you enable AutomaticItemReturn, SIP will trigger an eventual transfer to home branch when checking in. If disabled, it will not but the station receives an alert to notify the user. But the SIP response for both cases is actually the same. The code shows this: if ($messages->{NeedsTransfer}) { $self->{item}->destination_loc($messages->{NeedsTransfer}); $self->alert_type('04'); # send to other branch } if ($messages->{WasTransfered}) { # set into transit so tell unit $self->{item}->destination_loc($item->homebranch); $self->alert_type('04'); # send to other branch } The destination location will be the same in both cases. And the alert number is the same too. How could the SIP station 'know' that the transfer is done already or still needs to? Both SIP responses contains AO holding branch, AQ destination, CT destination and CV 04. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 28

[Bug 37273] New: Add ID column to Agreements table in the ERM
by bugzilla-daemon＠bugs.koha-community.org 06 Aug '25

06 Aug '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37273 Bug ID: 37273 Summary: Add ID column to Agreements table in the ERM Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: ERM Assignee: jonathan.druart(a)gmail.com Reporter: esther.melander(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: jonathan.druart(a)gmail.com, jonathan.field(a)ptfs-europe.com, martin.renvoize(a)ptfs-europe.com, matt.blenkinsop(a)ptfs-europe.com, pedro.amorim(a)ptfs-europe.com Created attachment 168606 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=168606&action=e… ERM ID number appended to agreement name When creating an Agreement or License in the ERM, an ID number is added to the agreement or license name. If it is necessary for the ID number to be visible, it should be in a separate column from the name. Having the ID number appended to the name is a little confusing (see example image). Another option is to hide the hide ID number if it is not needed. -- You are receiving this mail because: You are watching all bug changes.

1 34

[Bug 32742] New: Patron's lists are not in alphabetical order
by bugzilla-daemon＠bugs.koha-community.org 06 Aug '25

06 Aug '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32742 Bug ID: 32742 Summary: Patron's lists are not in alphabetical order 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: hammat.wele(a)inlibro.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com In the patron module, the list under 'Add to patron list' is not in alphabetical order -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 40

[Bug 25019] New: Non standard initialization in ViewPolicy filter
by bugzilla-daemon＠bugs.koha-community.org 06 Aug '25

06 Aug '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25019 Bug ID: 25019 Summary: Non standard initialization in ViewPolicy filter Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: koha-bugs(a)lists.koha-community.org Reporter: tomascohen(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org The ViewPOlicy filter has its own method for initializing its values, and then using its variables. This should be homogeneous through the filters. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 14

[Bug 36660] New: Make Authorities 'see from' searches more specific
by bugzilla-daemon＠bugs.koha-community.org 06 Aug '25

06 Aug '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36660 Bug ID: 36660 Summary: Make Authorities 'see from' searches more specific Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Searching Assignee: koha-bugs(a)lists.koha-community.org Reporter: aleisha(a)catalyst.net.nz QA Contact: testopia(a)bugs.koha-community.org When searching for an authority, 'see from' unlinked headings show as links that conduct new authority searches. These searches are 'any' and 'contains' searches so they end up being quite wide and unspecific, potentially producing more results than the original search that suggested this 'see from' heading. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 19

[Bug 35134] New: cn_browser.pl pop-up size should be configurable
by bugzilla-daemon＠bugs.koha-community.org 06 Aug '25

06 Aug '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35134 Bug ID: 35134 Summary: cn_browser.pl pop-up size should be configurable Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Cataloging Assignee: koha-bugs(a)lists.koha-community.org Reporter: lucas(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl To recreate: 1. Use the cn_browser.pl plugin for the 952$o ( call number ) 2. Add or edit an item and select the `...` to the right of the call number field. 3. The pop-up is hardcoded as 500px x 400px pop-up. 4. Some librarians would like to be able to change the size of this. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 36