May 2017 - Koha-bugs - lists.koha-community.org

[Bug 6758] Capture membership renewal date for reporting purposes
by bugzilla-daemon＠bugs.koha-community.org 01 May '17

01 May '17

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=6758 Katrin Fischer <katrin.fischer(a)bsz-bw.de> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Needs Signoff |Signed Off Patch complexity|--- |Trivial patch -- You are receiving this mail because: You are watching all bug changes. You are the QA Contact for the bug.

1 0

[Bug 18509] New: Minor performance improvement for overdue_notices.pl
by bugzilla-daemon＠bugs.koha-community.org 01 May '17

01 May '17

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=18509 Bug ID: 18509 Summary: Minor performance improvement for overdue_notices.pl Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Command-line Utilities Assignee: gmcharlt(a)gmail.com Reporter: martin.renvoize(a)ptfs-europe.com QA Contact: testopia(a)bugs.koha-community.org CC: robin(a)catalyst.net.nz Don't re-instantiate Koha::Calendar objects unnecessarily We were calling Koha::Calender->new on the same branchcode within a set of nested loops. This is just silly, only one object is required. -- You are receiving this mail because: You are watching all bug changes.

1 2

[Bug 12262] Searching patrons by extended attribute should be a search field
by bugzilla-daemon＠bugs.koha-community.org 01 May '17

01 May '17

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12262 Marjorie Barry-Vila <marjorie.barry-vila(a)ccsr.qc.ca> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |marjorie.barry-vila(a)ccsr.qc | |.ca -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 6473] Test bug for Git-bz
by bugzilla-daemon＠bugs.koha-community.org 01 May '17

01 May '17

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=6473 Katrin Fischer <katrin.fischer(a)bsz-bw.de> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Needs Signoff |Patch doesn't apply -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 5620] Capture Mode of payment
by bugzilla-daemon＠bugs.koha-community.org 01 May '17

01 May '17

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5620 Katrin Fischer <katrin.fischer(a)bsz-bw.de> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |katrin.fischer(a)bsz-bw.de Status|Needs Signoff |In Discussion --- Comment #17 from Katrin Fischer <katrin.fischer(a)bsz-bw.de> --- Hi all, some thoughts while looking at this. At the moment we already have a way to display the mode of payment when the fine is paid via SIP. In this case different accounttype values are used: >From pay.tt: [% SWITCH line.accounttype %] [% CASE 'Pay' %]Payment, thanks [% CASE 'Pay00' %]Payment, thanks (cash via SIP2) [% CASE 'Pay01' %]Payment, thanks (VISA via SIP2) [% CASE 'Pay02' %]Payment, thanks (credit card via SIP2) ... I think we should try and not have 2 separate ways of doing this depending on payment at the desk or at the self check as this will lead to more confusion and also make it harder to wrote reports etc. We could also discuss if this should be an authorised value or not. The advantage is, that the library can change it. The disadvantage is that the disadvantage is, that we can only display the values in one langauge at the moment. With the accounttype approach, we'd have to agree on a set of payment methods, but those would be translatable. I am changing this to 'in Discussion'. Please note that this does also currently not apply. -- You are receiving this mail because: You are the QA Contact for the bug. You are watching all bug changes.

1 0

[Bug 4461] Context-sensitive report a problem screen
by bugzilla-daemon＠bugs.koha-community.org 01 May '17

01 May '17

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=4461 Katrin Fischer <katrin.fischer(a)bsz-bw.de> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Needs Signoff |Failed QA --- Comment #9 from Katrin Fischer <katrin.fischer(a)bsz-bw.de> --- Really like the feature! Maybe we should add something like this to staff too? Possible problems: - Instead of tabs have a simple pull down to switch the recipient. At the moment, if you have typed up your message and then change your mind about whom to send it to, you have to start over as the text won't carry over from one tab to the other. - When submitting a problem report to the aministrator and there is no branch email supplied, the 'success' message and the 'error' message will both show at the same time after submitting. This might be confusing to the patron. Maybe we could avoid that by showing the 'error' next to the submit button or if we didn't have the tabs, not show the option to email the library at all, when there is no email address set for the branch? - There are some constraints with email sending if you are hosted and using the provider's mail server. So a while ago we have added branchreplyto (branches) and ReplyToDefault (system preference). It would be cool if you could check those first and email there if they are set and then fall back to branchemal and KohaAdminEmailAddress (like it's done for overdues etc.) - If you are not logged in when clicking on 'report a bug' the problem will be reported against the opac-reportproblem page. Questions: - I know that the feature can be hidden using the id (thx!), but maybe this should also be a preference? - How will the table in the database be maintained? Is there a way to empty it or plans to make it accessible from the GUI? -- You are receiving this mail because: You are the QA Contact for the bug. You are watching all bug changes.

1 0

[Bug 12027] Shibboleth authentication for staff client
by bugzilla-daemon＠bugs.koha-community.org 01 May '17

01 May '17

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12027 --- Comment #24 from Martin Renvoize <martin.renvoize(a)ptfs-europe.com> --- (In reply to M. Tompsett from comment #23) > (In reply to Martin Renvoize from comment #13) > > https://wiki.koha-community.org/wiki/Shibboleth_Configuration > > Sweet, tangentially, do we have attempts at other authentication methods? > Also, we should also have a bug for changing the StaffBaseURL to include the > protocol. After all, shibboleth requires https, does it not? This patch does allow fallback logins as per OPAC shibboleth, although due to the nature of shibboleth the same caveats apply (i.e. once you've clicked the 'login via shibboleth' link and been redirected to the IdP, if you fail to login you won't get redirected back to the koha client, so you'll have to navigate back yourself to use a fallback method. This is protocol specific and at the IdP end, there's no way to fix this at the koha side) Bug 18506 allows for a 'Shibboleth Only' mode should you wish to use shibboleth in that way. Hmm, I must admit I'd lost track fo the StaffBaseURL preference and whether it allowed specifying a protocol or not now; I best check up on that one. Cheers -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 4461] Context-sensitive report a problem screen
by bugzilla-daemon＠bugs.koha-community.org 01 May '17

01 May '17

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=4461 Katrin Fischer <katrin.fischer(a)bsz-bw.de> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Patch doesn't apply |Needs Signoff --- Comment #8 from Katrin Fischer <katrin.fischer(a)bsz-bw.de> --- Ok... partially talking nonsense. It DOES currently apply! -- You are receiving this mail because: You are the QA Contact for the bug. You are watching all bug changes.

1 0

[Bug 4461] Context-sensitive report a problem screen
by bugzilla-daemon＠bugs.koha-community.org 01 May '17

01 May '17

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=4461 Katrin Fischer <katrin.fischer(a)bsz-bw.de> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |katrin.fischer(a)bsz-bw.de Status|Needs Signoff |Patch doesn't apply --- Comment #7 from Katrin Fischer <katrin.fischer(a)bsz-bw.de> --- Hi Aleisha, this doesn't apply. It is recommended to have the changes to the Schema in a separate patch, because it's likely to conflict a lot. This way one can opt to not apply the patch and run the schema update locally when testing or pushing and you don't have to rebase as often. https://wiki.koha-community.org/wiki/Database_updates#Changes_with_DBIx::Cl… -- You are receiving this mail because: You are watching all bug changes. You are the QA Contact for the bug.

1 0

[Bug 3311] Statistical reports should error if row and column aren' t selected
by bugzilla-daemon＠bugs.koha-community.org 01 May '17

01 May '17

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=3311 --- Comment #48 from M. Tompsett <mtompset(a)hotmail.com> --- (In reply to Katrin Fischer from comment #47) > While testing this I noticed that the Acquisitions and Holds statistics have > column and row preselected - could this be a more elegant way of solving > this problem? It is a "less is more" type solution. Though, someone would need to specify what row and columns are picked by default. And since the original report says, "When running Statistical Reports, interface does not clearly specify that both a column and a row must be selected. User is able to generate a report with selection of just row. Koha should either error out, or add instructions on-screen indicating both column and row are required." It says nothing of defaults, hence this solution. > What I don't like about this patch is the changes to the pull downs. Instead > of empty for 'non-filtered' it shows a text now. Quickly scanning the form, > this makes it much harder to see, what was actually filtered on (lots of > text). This is not part of the problem description and should be dealt with > and discussed separately. True, I creeped the scope to include fixing the HTML. The HTML as it is triggered validation errors. Owen had suggested his preference would be some text describing what the actual blank value means. I can provide another patch to reset those parts. > Sorry, not signing off. Not sure which status to set - in Discussion? I suppose. -- You are receiving this mail because: You are watching all bug changes.

1 0