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

[Bug 9118] Show only sensible options when editing a unique holiday
by bugzilla-daemon＠bugs.koha-community.org 06 Oct '20

06 Oct '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=9118 Owen Leonard <oleonard(a)myacpl.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Patch complexity|--- |Small patch Status|Needs Signoff |Signed Off -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 25633] New: Update debian/control.ini file
by bugzilla-daemon＠bugs.koha-community.org 06 Oct '20

06 Oct '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25633 Bug ID: 25633 Summary: Update debian/control.ini file Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Packaging Assignee: koha-bugs(a)lists.koha-community.org Reporter: mtj(a)kohaaloha.com QA Contact: testopia(a)bugs.koha-community.org CC: mirko(a)abunchofthings.net This patch updates the debian/control.ini file for the 20.05 release cycle -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 16

[Bug 12617] Koha should let admins to configure automatically generated password complexity/difficulty
by bugzilla-daemon＠bugs.koha-community.org 06 Oct '20

06 Oct '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12617 Emmi Takkinen <emmi.takkinen(a)outlook.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #110528|0 |1 is obsolete| | --- Comment #30 from Emmi Takkinen <emmi.takkinen(a)outlook.com> --- Created attachment 111299 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=111299&action=e… Bug 12617: Add new regex patterns to password_check.inc This patch adds new regex patterns to follow into password_check.inc files. To test: 1. Create or find existing patron. 2. Set or edit invalid password for patron in OPAC and staff interfaces: a) create and edit patron pages b) 'Change password' pages 3. Confirm alert text next to input field is displayed and it follows set passwordpolicy. Sponsored-by: Koha-Suomi Oy -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 12617] Koha should let admins to configure automatically generated password complexity/difficulty
by bugzilla-daemon＠bugs.koha-community.org 06 Oct '20

06 Oct '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12617 Emmi Takkinen <emmi.takkinen(a)outlook.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #110527|0 |1 is obsolete| | --- Comment #29 from Emmi Takkinen <emmi.takkinen(a)outlook.com> --- Created attachment 111298 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=111298&action=e… Bug 12617: DO NOT PUSH! Schema change -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 12617] Koha should let admins to configure automatically generated password complexity/difficulty
by bugzilla-daemon＠bugs.koha-community.org 06 Oct '20

06 Oct '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12617 Emmi Takkinen <emmi.takkinen(a)outlook.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #110526|0 |1 is obsolete| | --- Comment #28 from Emmi Takkinen <emmi.takkinen(a)outlook.com> --- Created attachment 111297 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=111297&action=e… Bug 12617: Koha should let admins to configure automatically generated password complexity/difficulty Adds simple password policy(with regards to complexity) management into categories: - Per category password policy: admins can configure what kind of passwords get generated in member-passwords. User-created passwords are also checked against the policy if it is defined and complexity is enforced for every user based on their set category. - Predefined policies: - simplenumeric: the digits 0-9 allowed only - alphanumeric: passwords must contain only the digits 0-9 and lowercase and uppercase characters. Special characters are not allowed. - complex: patrons are required to use complex passwords containing numbers, uppercase and lowercase characters and special characters. Old passwords for excisting patrons are not affected. To test: 1. Apply this patch and update database. 2. Navigate to categories.pl and note there is new column 'Password policies' has been added. 3. Edit some categories and set password policy for them. 4. Set some values to sysprefs 'minPasswordLength', 'minAlnumPasswordLength' and 'minComplexPasswordLength'. Staff interface: 1. Create new patron. 2. Set their password against their categorys policy and save. 3. Error message is displayed (with content depending on password policy). 4. Set acceptable password and save succesfully. 5. Repeat steps 2-3-4 on patron edit page. 6. Repeat steps 2-3-4 on 'Change password' page. OPAC: 1. Enable 'OpacPasswordChange' and 'OpacResetPassword'. 2. On OPAC, repeat what you did on staff interface (on create, edit and 'Change your password'. 3. Confirm errors are displayed correctly and saving works. 4. Log out and go to 'Forgotten password recovery' page. 5. Send and receive email for password recovery. 6. Set unacceptable password and save, confirm correct error is displayed. 7. Set acceptable password and save succesfully. REST API: 1. With your preferred REST client (curl e.g) sent POST request to /api/v1/patrons/{patron_id}/password with 'password' and 'password_2' parameters. 2. Confirm correct error message is displayed when sending password against password policy. 3. Confirm password is changed when acceptable password is send. Also prove t/AuthUtils.t and t/db_dependent/api/v1/patrons_password.t Sponsored-by: Koha-Suomi Oy -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 9805] Lost items are un-lost if returned, but not if renewed
by bugzilla-daemon＠bugs.koha-community.org 06 Oct '20

06 Oct '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=9805 Martin Renvoize <martin.renvoize(a)ptfs-europe.com> changed: What |Removed |Added ---------------------------------------------------------------------------- See Also| |https://bugs.koha-community | |.org/bugzilla3/show_bug.cgi | |?id=26209 -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 12617] Koha should let admins to configure automatically generated password complexity/difficulty
by bugzilla-daemon＠bugs.koha-community.org 06 Oct '20

06 Oct '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12617 --- Comment #27 from Emmi Takkinen <emmi.takkinen(a)outlook.com> --- (In reply to David Cook from comment #26) > Does Koha-Suomi Oy already have these patches running in Koha? > > I'm going to mark as Failed QA, as I think the current password policies > won't be workable for many Koha implementations. Thanks David for looking into this! There's a lot to consider there... We've had the first patch running in Koha for a quite while now (not as it's implemented here of course, this is a rebased patch against master). We run version 17.05 and don't have password_check.inc so second patch applies to current community master. I'm thinking of scraping those äöåÄÖÅ's from the first patch (and fixing that spelling error in the second) for now. Then I'll add new patch with improved regexs (that is if we need them). If someone has more opinions on this please comment! -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 25591] New: Update debian/control for debian 10
by bugzilla-daemon＠bugs.koha-community.org 06 Oct '20

06 Oct '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25591 Bug ID: 25591 Summary: Update debian/control for debian 10 Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: blocker Priority: P5 - low Component: Packaging Assignee: koha-bugs(a)lists.koha-community.org Reporter: mtj(a)kohaaloha.com QA Contact: testopia(a)bugs.koha-community.org CC: mirko(a)abunchofthings.net this patch updates the debian/control for koha 20.05 on debian 10 -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 70

[Bug 23249] New: Print hold slips without confirmation for multiple locations
by bugzilla-daemon＠bugs.koha-community.org 06 Oct '20

06 Oct '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23249 Bug ID: 23249 Summary: Print hold slips without confirmation for multiple locations Change sponsored?: --- Product: Koha Version: 18.11 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: jdemuth(a)roseville.ca.us QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com Depends on: 19383 Our library just upgraded to 18.11.06 and we tested bug 19383 which allows printing hold slips without confirmation. Everything worked as expected but we noticed this only works if you have one library location. This does not work for multiple library locations and looks like it overwrites the transfer and prints the hold slip making it confusing for staff. After the slip prints the screen displays both the hold box and then the transfer box below it. Here is a test plan of how to recreate this issue: 1. Place an item on hold that is at Library A and select Library B as the pick up location. 2. Check in item at Library A to trigger the transfer. 3. A hold slip still automatically prints and states its on hold at Library B. 4. Once you close the pop up box, you can see two alerts, one to reprint the hold slip and then the actual transfer prompt is below. Thanks, Jen DeMuth Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19383 [Bug 19383] Print hold slips without confirmation -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 7

[Bug 23292] New: Use TransferSlip when transfering item which is on hold
by bugzilla-daemon＠bugs.koha-community.org 06 Oct '20

06 Oct '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23292 Bug ID: 23292 Summary: Use TransferSlip when transfering item which is on hold Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Notices Assignee: koha-bugs(a)lists.koha-community.org Reporter: johanna.raisa(a)koha-suomi.fi QA Contact: testopia(a)bugs.koha-community.org Now when Koha asks to transfer an item which is on hold it will give HoldSlip to a librarian. We have TransferSlip which is used in other transfering situations, so we should use this also when transfering hold item. The HoldSlip should trigger when the item is checked in after transfer to the right branch. Combining the hold and transfer slips might get confusing if the slip is used on self-service pickup as we are doing in Finnish public libraries. Also there comes the data protection issue if other patrons can see too much information about holds. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 19