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

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

08 Jul '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12617 koha-US bug tracker <bugzilla(a)koha-us.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |bugzilla(a)koha-us.org -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 24538] New: REMOTE_USER set to undef if koha_trusted_proxies contains invalid value
by bugzilla-daemon＠bugs.koha-community.org 08 Jul '20

08 Jul '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=24538 Bug ID: 24538 Summary: REMOTE_USER set to undef if koha_trusted_proxies contains invalid value Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: koha-bugs(a)lists.koha-community.org Reporter: dcook(a)prosentient.com.au QA Contact: testopia(a)bugs.koha-community.org If koha_trusted_proxies contains an invalid or unparseable value, say due to a typo, like "1.1.1.", it'll treat it as a 0.0.0.0/0 mask and match against everything. In my tests, this leads to REMOTE_USER being set to undef. (On the plus side, at least a 0.0.0.0/0 mask leads to zero privileges rather than all privileges.) -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 18

[Bug 25949] New: Date and time displaying AM when it should show PM
by bugzilla-daemon＠bugs.koha-community.org 08 Jul '20

08 Jul '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25949 Bug ID: 25949 Summary: Date and time displaying AM when it should show PM Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: trivial Priority: P5 - low Component: About Assignee: koha-bugs(a)lists.koha-community.org Reporter: dcook(a)prosentient.com.au QA Contact: testopia(a)bugs.koha-community.org When TimeFormat is 12 hours, 07/08/2020 03:23 AM is being shown instead of 07/08/2020 03:23 PM. At a glance, it's because we use output_pref both in about.pl and about.tt and it's getting confused. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 4

[Bug 6815] Capture member photo via webcam
by bugzilla-daemon＠bugs.koha-community.org 08 Jul '20

08 Jul '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=6815 --- Comment #42 from M. Tompsett <mtompset(a)hotmail.com> --- I see the attempt to javascript the picture up, but it is failing, because the click() hijacks and returns, never to run the ajaxiness. I have an idea... perhaps I'll play with it a bit this week. It would be nice to solve a 4 digit bugzilla. Sorry I have been distracted with other projects lately. :) -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 6815] Capture member photo via webcam
by bugzilla-daemon＠bugs.koha-community.org 08 Jul '20

08 Jul '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=6815 --- Comment #41 from M. Tompsett <mtompset(a)hotmail.com> --- (In reply to Jonathan Druart from comment #40) > It does not work for me/my webcam: > * Firefox: > I see "Take", but then the modal displays with "No permission to use camera" > in an alert. If I close it, I see the "Take the patron's picture" button in > the modal, but it generates a black picture. > > * Chromium: No "Take" > > > The browsers does not ask me if I want to allow the webcam for this page. > > The webcam seems to work with cheese and hangout. Greetings. I ran in Chrome (Version 83.0.4103.116 (Official Build) (64-bit) on Ubuntu 20.04 LTS vagrant up'd to stretch and accessed by localhost:8081), and it worked just fine. I then run in Chromium (Version 81.0.4044.138 (Official Build) Built on Ubuntu , running on Ubuntu 20.04 (64-bit) same localhost:8081), without closing the Chrome, and it gave me the error you got in Firefox. Once I closed Chrome, and retried in Chromium, it worked. It worked for me in Opera (69.0.3686.49) too. I even tried firefox (78.0.1 (64-bit)). And while it was much noisier (Are you sure you want permissions for this? Really? What about this?), it worked for me too. Did you have cheese and hangout open when you tested this? I think there may be some "Give me exclusive control!" type issues between the various programs. -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 15448] OPACHiddenItems show in OPAC when patron places a hold on a specific item
by bugzilla-daemon＠bugs.koha-community.org 07 Jul '20

07 Jul '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15448 --- Comment #12 from Christopher Brannon <cbrannon(a)cdalibrary.org> --- (In reply to Chris Kirby from comment #11) > I would like to add another vote to seeing this bug fixed. +1 -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 0

[Bug 15448] OPACHiddenItems show in OPAC when patron places a hold on a specific item
by bugzilla-daemon＠bugs.koha-community.org 07 Jul '20

07 Jul '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15448 Chris Kirby <chris.kirby(a)ilsleypubliclibrary.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |chris.kirby@ilsleypubliclib | |rary.org --- Comment #11 from Chris Kirby <chris.kirby(a)ilsleypubliclibrary.org> --- I would like to add another vote to seeing this bug fixed. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 0

[Bug 14648] Batch remove reserve items
by bugzilla-daemon＠bugs.koha-community.org 07 Jul '20

07 Jul '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14648 --- Comment #18 from Joe Sikowitz <joe(a)flo.org> --- Hi Nick, These patches keep things simple and work as expected. Blocker: 1 - If I enter barcodes that are not in any courses I report successful deletion from all courses - I don't think that's right I'm going to fix this one and readd the patch. Couple questions: 1 - Why not a bulk option to remove from a single course? I've already submitted this patch and it has been signed off as bug 25606. 2 - Could the results report which courses the items were deleted from, at the very least maybe the number of courses it was removed from? This sounds reasonable. I'll look into adding it. 3 - I would rather see this use Objects, but CourseReserves could use a refactor as a whole I'm not sure what Objects you are referring to. Any information you can provide would be great. Thanks, Joe -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 22823] New: Koha::Library needs a method for obtaining the incoming email address
by bugzilla-daemon＠bugs.koha-community.org 07 Jul '20

07 Jul '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=22823 Bug ID: 22823 Summary: Koha::Library needs a method for obtaining the incoming email address 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: martin.renvoize(a)ptfs-europe.com QA Contact: testopia(a)bugs.koha-community.org Target Milestone: --- There's a code pattern emerging (in bug 5770 and bug 22821 at least to my knowledge) where we grab a branches email address to send notifications to the branch. However, it's prone to make mistakes in the fallback order for assigning that address so we should factor it out into a method that can be called from Koha::Library. Should be as simple as >sub to_email { > my $self = shift; > return $self->branchreplyto || $self->branchemail || C4::Context->preference('ReplytoDefault') || C4::Context->preference('KohaAdminEmailAddress'); >} along with some appropriate POD and a walk of the codebase to replace existing occurrences of the pattern. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 46

[Bug 14648] Batch remove reserve items
by bugzilla-daemon＠bugs.koha-community.org 07 Jul '20

07 Jul '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14648 Nick Clemens <nick(a)bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |nick(a)bywatersolutions.com Status|Signed Off |Failed QA --- Comment #17 from Nick Clemens <nick(a)bywatersolutions.com> --- (In reply to Katrin Fischer from comment #16) > QA team ... I signed off, can one of you take over here please? These patches keep things simple and work as expected. Blocker: 1 - If I enter barcodes that are not in any courses I report successful deletion from all courses - I don't think that's right Couple questions: 1 - Why not a bulk option to remove from a single course? 2 - Could the results report which courses the items were deleted from, at the very least maybe the number of courses it was removed from? 3 - I would rather see this use Objects, but CourseReserves could use a refactor as a whole -- You are receiving this mail because: You are watching all bug changes.

1 0