[Koha-bugs] [Bug 20962] Overhaul to notices

[bugzilla-daemon at bugs.koha-community.org]

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20962

--- Comment #10 from Katrin Fischer <katrin.fischer at bsz-bw.de> ---
Hi all,

after reading the RFC more closely I have some additional comments, Step 1 is
the main concern for us:

Comment on: Step 1 - Move Overdues into member messaging preferences

I think this change is not as straightforward as it sounds at first and could
cause unwanted changes in behaviour and regressions for some use cases.

At the moment it's possible to:
- Configure per patron category, if overdue notices will be sent
- Configure per library, patron category and notice level which notice template
will be used.
- Configure per library, notice level, patron category and notice level which
transport types will be used (multiple).

I assume that with the new feature the notification methods would be moved out
of notice triggers into the messaging preferences table.

1) Library: Looking at the overdue_notices.pl script I understand that notices
are usually grouped by items.homebranch using the settings for the said
library. So multiple libraries in one Koha installation can handle their
notices differently. The patron can receive different notices by different
transport types from different branches.

With the change as I understand it, this would change and only one notification
methods setting would apply to all libraries.

2) Notification method: The 'Note' on the RFC mentions that for mutiple levels
of overdues, they should be included in one notice type for messaging
preferences. I understand this would mean one line in the table for all 3
levels of notices applied with the settings made there applied to all of them.

Currently message transport types can be different per library and notice
level. I think this would no longer work with the suggested change. A very
common use case here is:
Sent the first 2 overdues by email, sent the 3rd in a more formal way as a
postal notice.

If this would no longer be possible it would cause big problems for us.

3) Patron's choice: As stated before it would cause a problem for us, if
patrons can opt out of overdue notices themselves. Overdue notices appearing in
the messaging preferences in OPAC should be a configurable option to allow for
different use cases.

4)  ON/OFF swith: Currently there is a switch on patron category level. I
understand that the intention would be to make this more granular to be by
library and patron category?

Comment on: Step 2 - Enable 'postal' as a specific option rather than simply a
fallback,for all notice types

Would the fallback to postal for users without valid email address or mobile
number still be available? It could be optional, but we are relying quite
heavily on this behaviour at the moment.

Comment on: Step 3 - option to process all print notices together

Is this refering to the functionality currently implemented in
gather_print_notices.pl?

For privacy reasons there should always be an option to get the files with
notices from the server instead of sending them by email (for example using Bug
11317 - Add a way to access files from the intranet)

Comment on: Step 4 - extend <item> tags to other circulation notices

I think this would be great. As we are planning to obsolete the <<...>> syntax
by TT at some point, it would make sense to ensure there is a working TT
equivalent for all notices too.

Comment on: Step 6 - Allow circulation notices to be created for any item
status change

A tool to send notices based on configurable triggers sounds like a great idea.

Comment on: Step 8 - Do not disturb for message queue

I like the idea and it definitely makes sense for SMS. Only a technical thing
maybe: As the scheduled cronjobs generate notices and add them into the message
queue, it would probably make sense to make the change on the processing of the
message_queue, allowing it to ignore notices of some types during the DND time
periods.

-- 
You are receiving this mail because:
You are the assignee for the bug.
You are watching all bug changes.