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

[Bug 19660] New: Set borrower password on first login from self registration
by bugzilla-daemon＠bugs.koha-community.org 03 Oct '23

03 Oct '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19660 Bug ID: 19660 Summary: Set borrower password on first login from self registration 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: liz(a)catalyst.net.nz QA Contact: testopia(a)bugs.koha-community.org Currently when a borrower has confirmed their account, we show them their username and password after confirmation. I propose instead of doing this, we allow the user to set their own password after they have confirmed their account. We could use parts of the forgot-my-password code to do this, for example pre-populating the username/email bits of the form, and asking the user to fill in their new password twice. We really shouldn't be showing the password on the screen, ever. Let's not do that anymore. -- You are receiving this mail because: You are watching all bug changes.

1 20

[Bug 34974] New: search_for_data_inconsistencies.pl: Can't call method "get_column"
by bugzilla-daemon＠bugs.koha-community.org 03 Oct '23

03 Oct '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=34974 Bug ID: 34974 Summary: search_for_data_inconsistencies.pl: Can't call method "get_column" Change sponsored?: --- Product: Koha Version: 20.11 Hardware: All OS: Linux Status: NEW Severity: normal Priority: P5 - low Component: Command-line Utilities Assignee: koha-bugs(a)lists.koha-community.org Reporter: mik(a)adminkuhn.ch QA Contact: testopia(a)bugs.koha-community.org CC: robin(a)catalyst.net.nz When calling the script "search_for_data_inconsistencies.pl" the only output is the following: $ sudo koha-shell -c "perl /usr/share/koha/bin/maintenance/search_for_data_inconsistencies.pl" instancename Can't call method "get_column" on an undefined value at /usr/share/koha/bin/maintenance/search_for_data_inconsistencies.pl line 157. This happens when using Koha 20.11.02 with MariaDB 10.3.39, running on Debian GNU/Linux 10. According to Jonathan Druart (3 October 2023) this can be considered as a bug for this script, and it seems (looking at the code) that the bug still exists in master. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 0

[Bug 19698] New: "Add message" for patron don' t use OPAC description if message type is OPAC
by bugzilla-daemon＠bugs.koha-community.org 03 Oct '23

03 Oct '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19698 Bug ID: 19698 Summary: "Add message" for patron don't use OPAC description if message type is OPAC 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: sophie.meynieux(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com If you want to add a message to a patron, you can choose OPAC or intranet message type. Predefined messages are defined in BOR_NOTES authorised value. But OPAC description is never used even if message type is OPAC -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 8

[Bug 32807] New: No need to fetch all if we need to know if one exist
by bugzilla-daemon＠bugs.koha-community.org 03 Oct '23

03 Oct '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32807 Bug ID: 32807 Summary: No need to fetch all if we need to know if one exist Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: ERM Assignee: jonathan.druart+koha(a)gmail.com Reporter: jonathan.druart+koha(a)gmail.com CC: jonathan.druart+koha(a)gmail.com, jonathan.field(a)ptfs-europe.com, martin.renvoize(a)ptfs-europe.com, pedro.amorim(a)ptfs-europe.com Depends on: 32030 In (at least) AgreementsList we are calling fetchAgreements which fetch all the agreements, to know if we display the table (that will fetch again the first X agreements). We need a fetchCountAgreements (similar to fetchCountLocalPackages) instead. I think we discussed that already somewhere else. Anyone willing to provide a patch to make their grip on Vue and the ERM module? Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32030 [Bug 32030] Electronic resource management (ERM) -- You are receiving this mail because: You are watching all bug changes.

1 25

[Bug 26973] New: 20.05.04 - extendedPatronAttributes not showing during selfregistration
by bugzilla-daemon＠bugs.koha-community.org 03 Oct '23

03 Oct '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26973 Bug ID: 26973 Summary: 20.05.04 - extendedPatronAttributes not showing during selfregistration Change sponsored?: --- Product: Koha Version: 20.05 Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: jan.michael.mueck(a)uni-hamburg.de QA Contact: testopia(a)bugs.koha-community.org Created attachment 113307 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=113307&action=e… screenshots and irc chat In the Koha Version 20.05.04 the extendedPatronAttributes not showing during selfregistration. I created a PatronAttribute "Matrikelnummer" which is configured to be shown and editable in OPAC. It also is searchable. The attribut is set for all user and bibtypes. PatronSelfRegistrationVerifyByEmail is disabled extendedPatronAttributes is enabled I tested the same configuration on another server with koha version 20.05.01. The field "Matrikelnummer" is shown during the selfregistration process and the entered values are set correctly in the mysql database and userdetails. -- You are receiving this mail because: You are watching all bug changes.

1 26

[Bug 30120] New: Allow extended attributes during self registration when using PatronSelfRegistrationVerifyByEmail
by bugzilla-daemon＠bugs.koha-community.org 03 Oct '23

03 Oct '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=30120 Bug ID: 30120 Summary: Allow extended attributes during self registration when using PatronSelfRegistrationVerifyByEmail 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: nick(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 15

[Bug 21388] New: Add ability to hide Non-public Notes from Circulation Page
by bugzilla-daemon＠bugs.koha-community.org 02 Oct '23

02 Oct '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=21388 Bug ID: 21388 Summary: Add ability to hide Non-public Notes from Circulation Page Change sponsored?: --- Product: Koha Version: 17.11 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Staff Client 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 In a previous bug 19806, non-public notes were requested for the library to have the ability to hide this field (non public note/ itemnotes) in checkin tables. This field "itemnotes" was added to the Configure Columns to allow a library to choose or not choose to have this field visible. This feature would also be nice in the issues (circulation) screen. When a staff member is checking out an item to the patron, they might not necessarily need to see the non-public note during checking out in addition to checking in. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 11

[Bug 21378] New: Add filters in reserve/request.pl
by bugzilla-daemon＠bugs.koha-community.org 02 Oct '23

02 Oct '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=21378 Bug ID: 21378 Summary: Add filters in reserve/request.pl Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Hold requests Assignee: koha-bugs(a)lists.koha-community.org Reporter: black23(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com Hi, filter are very useful function if holdings view. If librarian manage hold request on periodical item (issue) isn't easy to find specific item from many. Filters allow sort items or find specific item very easy and quick. For newspapers or magazines we shoudl use Serial enumeration / chronology. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 4

[Bug 12769] Manage fees for sending notices
by bugzilla-daemon＠bugs.koha-community.org 02 Oct '23

02 Oct '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12769 Katrin Fischer <katrin.fischer(a)bsz-bw.de> changed: What |Removed |Added ---------------------------------------------------------------------------- See Also| |https://bugs.koha-community | |.org/bugzilla3/show_bug.cgi | |?id=21371 -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 21370] New: Regular search and items search displays different info as Status
by bugzilla-daemon＠bugs.koha-community.org 02 Oct '23

02 Oct '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=21370 Bug ID: 21370 Summary: Regular search and items search displays different info as Status Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Searching Assignee: koha-bugs(a)lists.koha-community.org Reporter: magnus(a)libriotech.no QA Contact: testopia(a)bugs.koha-community.org Make sure you have a record with an item that has 952$1 (itemlost) = some value, e.g. 4. Look at the record in detail view. The items table will have a column called "Status", which displays the description of the LOST authorized value corresponding to the value in 952$i. Now do an item search that displays the same item. The table will have a column called Status, but you will not see the description from the detail view. If you look at the dropdown filter at the top of the Status column, it will show values from the NOT_LOAN category. I find this confusing. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 2