December 2018 - Koha-bugs - lists.koha-community.org

[Bug 19011] New: Display patron's own notices for patron user itself
by bugzilla-daemon＠bugs.koha-community.org 04 Jun '19

04 Jun '19

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19011 Bug ID: 19011 Summary: Display patron's own notices for patron user itself Change sponsored?: --- Product: Koha Version: 3.22 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Patrons Assignee: koha-bugs(a)lists.koha-community.org Reporter: jvr(a)fct.unl.pt QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com Dear Sir, I am still using version 3.22.07 and I am not aware if the option I trying to implement already exists in newer versions. I want the PATRONS to be able to access to their own notices as staff are able to do in, for example: (https://opac.sitename.com:8443/cgi-bin/koha/members/notices.pl?borrowernumb…) The reason is that there are too many complains as everybody says that they haven't receiced any notice emails for a million reasons; in other words no one wants to paid the fines... For this information already resides in the Koha's database tables and it is only a matter of querying it for the OPAC user (with authenticated login) please inform me how to acomplish this. Thank you in antecipation for an early reply. Victor do Rosário -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 2

[Bug 21936] New: Patrons do not have option on printed notices
by bugzilla-daemon＠bugs.koha-community.org 04 Jun '19

04 Jun '19

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=21936 Bug ID: 21936 Summary: Patrons do not have option on printed notices Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Notices Assignee: koha-bugs(a)lists.koha-community.org Reporter: cbrannon(a)cdalibrary.org QA Contact: testopia(a)bugs.koha-community.org Patrons do not have the ability to opt out of printed notices. Right now, selecting the e-mail option is the only way to turn off printed notices. Which is odd, because SMS doesn't do that. I think we should do one of two things: A) There should be a new column added to the patron messaging preferences that show check marks for all notices in a print column, and allow the patrons to opt out, like the others. E-mail should no longer negate printed. B) Change the check box to a dropdown, and have the choices of Print only, E-mail only, Both, or Neither. The column should be renamed Full Notice (because SMS/phone are treated differently. Personally, I think A is the better, straight forward choice. Less confusion. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 1

[Bug 20750] New: Allow timestamped auditing of ILL request events
by bugzilla-daemon＠bugs.koha-community.org 03 Jun '19

03 Jun '19

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20750 Bug ID: 20750 Summary: Allow timestamped auditing of ILL request events Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: ILL Assignee: koha-bugs(a)lists.koha-community.org Reporter: andrew.isherwood(a)ptfs-europe.com Currently there is no audit trail provided for ILL requests, this is required. At the most basic form this would be a timestamped record of changes of a request's status. It would be useful to be able to also record other arbitrary events. This bug proposes the addition of a requests_actions log that allows either the core ILL code or backends to record arbitrary events relating to a request. This could then be displayed in the UI as an "audit trail" or reported upon. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 186

[Bug 22049] New: MarkIssueReturned should rely on returndate only
by bugzilla-daemon＠bugs.koha-community.org 03 Jun '19

03 Jun '19

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=22049 Bug ID: 22049 Summary: MarkIssueReturned should rely on returndate only 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: tomascohen(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org Target Milestone: --- There's no need to pass the responsability of calculating the dropbox mode return date inside of it. We should get rid of it, and calculate dates in a single place to avoid bugs and code duplication. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 33

[Bug 20313] New: Article requests: Can we do without the processing notice ?
by bugzilla-daemon＠bugs.koha-community.org 03 Jun '19

03 Jun '19

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20313 Bug ID: 20313 Summary: Article requests: Can we do without the processing notice ? Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: m.de.rooy(a)rijksmuseum.nl QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com For each article request we switch to processing status, Koha sends a mail to the patron. It does not tell much. The patron already received a mail that acknowledges his request; so why not send a mail only when the request has been completed? In other words: can we remove AR_PROCESSING ? -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 6

[Bug 21364] New: Allow deletion of basket from vendor search/view
by bugzilla-daemon＠bugs.koha-community.org 02 Jun '19

02 Jun '19

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=21364 Bug ID: 21364 Summary: Allow deletion of basket from vendor search/view Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Acquisitions Assignee: nick(a)bywatersolutions.com Reporter: nick(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org -- You are receiving this mail because: You are watching all bug changes.

1 50

[Bug 21241] New: Set suggestion notices message_transport_type to sms if patrons has no email but smsalertnumber set
by bugzilla-daemon＠bugs.koha-community.org 31 May '19

31 May '19

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=21241 Bug ID: 21241 Summary: Set suggestion notices message_transport_type to sms if patrons has no email but smsalertnumber set 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: alexbuckley(a)catalyst.net.nz QA Contact: testopia(a)bugs.koha-community.org Presently the message_transport_type of suggestion module notices is hardcoded to email in C4/Suggestions.pm. If a patron does not have an email address set, but does have a smsalertnumber set then they will not receieve their suggestion notices. This patch introduces a conditional to C4/Suggestions.pm to check if no patron email exists AND a patron smsalertnumber does exist then the message_transport_type of the suggestion notice is set to 'sms'. Otherwise the message_transport_type is set to 'email'. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 38

[Bug 20537] New: Warnings in overdue_notices.pl
by bugzilla-daemon＠bugs.koha-community.org 30 May '19

30 May '19

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20537 Bug ID: 20537 Summary: Warnings in overdue_notices.pl Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Command-line Utilities Assignee: koha-bugs(a)lists.koha-community.org Reporter: katrin.fischer(a)bsz-bw.de QA Contact: testopia(a)bugs.koha-community.org CC: robin(a)catalyst.net.nz We've seen a warning from overdue_notices.pl: Use of uninitialized value in concatenation (.) or string at /usr/share/koha/bin/cronjobs/overdue_notices.pl line 575. I checked in our version and in master and think it happens for users withut a surname (organisations usually): 576 $borrowernumber = $data->{'borrowernumber'}; 577 my $borr = 578 $data->{'firstname'} . ', ' 579 . $data->{'surname'} . ' (' 580 . $borrowernumber . ')'; 581 $verbose Should we check here if firstname/surname are defined? -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 19

[Bug 21450] New: link_bibs_to_authorities.pl is caching searches without the auth type
by bugzilla-daemon＠bugs.koha-community.org 30 May '19

30 May '19

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=21450 Bug ID: 21450 Summary: link_bibs_to_authorities.pl is caching searches without the auth type Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: MARC Authority data support Assignee: koha-bugs(a)lists.koha-community.org Reporter: nick(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org It seems that the script stores the results of a search term using only the search term - not the authority type, this can be problematic Image A record containing both a subject and topic term: 650 _0 $aShort stories 655 __ $aShort stories And there being an authority record for each: Short stories AUTH_TYPE SU_TOPIC #1708 Short stories AUTH_TYPE GENRE #1709 The linker for the first stores: $cache->{Short stories} = 1708 and the genre link then reuses this search -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 27

[Bug 21831] New: Marc modification templates move all action moves only one field
by bugzilla-daemon＠bugs.koha-community.org 30 May '19

30 May '19

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=21831 Bug ID: 21831 Summary: Marc modification templates move all action moves only one field Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Tools Assignee: koha-bugs(a)lists.koha-community.org Reporter: pasi.kallinen(a)joensuu.fi QA Contact: testopia(a)bugs.koha-community.org If you have a marc modification template action to "move all fields XXX to YYY", and the field XXX has been repeated in a record, only the first XXX field is moved. Same applies to "copy" and "copy and replace" actions. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 17