Bug 20962 - Overhaul to notices
Summary: Overhaul to notices
Status: NEW
Alias: None
Product: Koha
Classification: Unclassified
Component: Notices (show other bugs)
Version: unspecified
Hardware: All All
: P5 - low enhancement with 10 votes (vote)
Deadline: 2018-11-01
Assignee: Bugs List
QA Contact: Testopia
URL: https://wiki.koha-community.org/wiki/...
Keywords:
Depends on:
Blocks:
 
Reported: 2018-06-19 05:05 UTC by Hugh Rundle
Modified: 2020-03-18 11:05 UTC (History)
10 users (show)

See Also:
Change sponsored?: Sponsored
Patch complexity: ---
Documentation contact:
Documentation submission:
Text to go in the release notes:
Version(s) released in:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Hugh Rundle 2018-06-19 05:05:39 UTC
Currently notices are run using effectively two separate systems. Overdue notices run using their own cron job, whilst everything else is either queued by the advance_notices cron or directly added to the message queue. Additionally, print overdues are treated differently to other overdues. This means the options available for print overdues considerably lag those available for other notice types, and there are confusing discrepencies between overdues, other notices, and print overdues and everything else.

Note that this enhancement is primarily aimed at modernising the way paper (postal) notices are managed, but as part of that it moves overdues under the same structure as other notices.

# Step 1 - Move Overdues into member messaging preferences
This should allow patrons (or staff on behalf of patrons) to:

  1. Select one or more notification methods (SMS, email etc)
  2. Choose not to be notified about Overdues at all
  3. Choose to receive a digest for overdues

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

# Step 3 - option to process all print notices together

# Step 4 - extend <item> tags to other circulation notices

# Step 5 - Allow for 'digesting' of all notices in queue regardless of type

# Step 6 - Allow circulation notices to be created for any item status change

More detail is provided in the RFC - once we have community feedback the details may change slightly.
Comment 1 Katrin Fischer 2018-06-19 06:06:25 UTC
Some comments on this:

>  2. Choose not to be notified about Overdues at all

Please make this optional. I think it would be a problem for libraries here as I already often have to assure libraries that this is one notice they can't decide about. The other notices are ok, but overdues especially when connected with fines are a different thing.

>  3. Choose to receive a digest for overdues

How would a digest option work? The other digests are for emails that would be send for one item each without the digest option, which we don't do for overdues right now?

For some of the other enhancements I think it would be good to break them out into separate bugs. The bigger the patch set, the harder it is to integrate.
Comment 2 Hugh Rundle 2018-06-19 06:21:33 UTC
Thanks Katrin

(In reply to Katrin Fischer from comment #1)
> Some comments on this:
> 
> >  2. Choose not to be notified about Overdues at all
> 
> Please make this optional. 

Do you mean use a syspref to make it optional to allow patrons to choose not to be notified? I don't have a problem with that, it's just at the moment there is no option to *allow* patrons to choose not to be notified. I personally think it's weird that they wouldn't want to get overdue notices, but we have had more than one request from patrons re this.

> 
> >  3. Choose to receive a digest for overdues
> 
> How would a digest option work? The other digests are for emails that would
> be send for one item each without the digest option, which we don't do for
> overdues right now?

Hmm, you're right, I think I've confused this with digesting the different levels of notice. e.g. if we have a level 1 overdue at 7 days, then level 2 at 21 days etc, we ideally want to be able to batch those together into different sections within one notice.


> For some of the other enhancements I think it would be good to break them
> out into separate bugs. The bigger the patch set, the harder it is to
> integrate.

Yes, I agree this should all be separate bugs, but at the moment it's an RFC so I didn't want to create a mess of bugs that may end up changing a lot.
Comment 3 Katrin Fischer 2018-06-19 06:24:52 UTC
Basically a way to not have the overdues notices show up in the configuration table in the OPAC (and maybe also in staff?). Maybe it could be generalized to have a multi-select preference for all notices. So libraries not providing holds can also hide the holds notice etc.
Comment 4 Hugh Rundle 2018-06-19 06:32:42 UTC
Ah, I realise what I did re digests.

The important thing here isn't overdues, it's "hold filled" - especially for print notices. 

At the moment you can't digest hold filled notices, which might make sense for SMS or email notices that go out immediately, but is a pain for print notices when a large number of holds become available for the same patron all on the same day.

There is more detail for this proposal in the RFC - link is at URL listed on this bug.
Comment 5 Jonathan Druart 2018-06-19 21:10:52 UTC
<item> is going to be deprecated, you should use the TT syntax for notice instead.
It basically means there will certainly no need to dev anything to support that (apart of adapting the template to your needs).
Comment 6 Lisette Scheer 2018-06-19 22:25:29 UTC
(In reply to Hugh Rundle from comment #0)
> 
> # Step 3 - option to process all print notices together
> 

It would be great if this could use the hierarchical groups function added in bug 16735 so that groups/districts in consortia could benefit from this enhancement. 
Lisette Scheer
Comment 7 George Williams (NEKLS) 2018-06-26 13:52:37 UTC
# Step 3 - option to process all print notices together:

We operate a library consortium that has 44 libraries and 51 library branches.  1 of those libraries is a district with 4 branches and they would like to be able to process all print notices at their headquarters branch.  Another of those libraries is a school distict with 5 branches and they would like to process all print notices at each separate branch.  Work on #3 that can offer the flexibility to accommodate that scenario would be welcomed and it would probably solve Lisette's situation as well.
Comment 8 Barton Chittenden 2018-07-02 16:41:39 UTC
(In reply to Jonathan Druart from comment #5)
> <item> is going to be deprecated, you should use the TT syntax for notice
> instead.
> It basically means there will certainly no need to dev anything to support
> that (apart of adapting the template to your needs).

When I first read through the RFC, this was the point that concerned me the most. Currently, we have the following ways of looping through detail inside of notices:

<<items.content>>

<item> </item>

----
Detail here
----

<checkedout> </checkedout> 
<overdue> </overdue> 
<news> </news> 

Whatever CLAIMSERIAL does.

Not all of these fit nicely with <item></item> -- and having a more flexible and consistent looping construct was one of Kyle's motivations for introducing TT into notices. TT exists as a parsing layer in all notices right now -- rather than extending <item> </item> tags, I would prefer to extend Koha/Template/Plugin to create more user friendly looping constricts in TT, then deprecate <<items.content>>, <item> </item>, the '----' detail, etc.
Comment 9 Joy Nelson 2018-07-02 20:53:12 UTC
> 
> # Step 5 - Allow for 'digesting' of all notices in queue regardless of type
> 

Our implementation team found this (#5) intriguing.  One email versus 3 emails is great.  Are you allowing for the option of not including certain messages in the digest?  For example, X library would not want overdue notices to be part of a larger digest message.  Overdue notices would be sent separately, but other messages could be digestible - member renew, checkout, predue, hold placed...

It's not listed in the initial message but on the RFC wiki page, you mention #8 "Do not disturb" option.  YES.  this would be so helpful!
Comment 10 Katrin Fischer 2018-07-06 14:37:57 UTC
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.
Comment 11 Barton Chittenden 2018-07-06 17:41:52 UTC
(In reply to Katrin Fischer from comment #10)

> 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.

To give another concrete case here, one of our partners has an Audio-Visual department in one of their libraries which lends laptops, video cameras, tablets etc. This department is organized as its own branch. They have very specialized notices and overdue triggers due to the monetary value of the items they're lending -- for this library, losing control of the timing content and method of notice delivery is not an option.

Another thing to keep in mind is that the library updating borrower messaging preferences is currently awkward -- the library can currently modify default messaging preferences, but in order for that to propagate, we have to run a script. If we move more control over borrower messaging preferences, then I think we need to have a more sophisticated system of allowing the library to a) control which options borrowers have control over (so that borrowers can't entirely disable overdue notices, for example) and b) some way of allowing borrowers to specify which preferences they want to stick when the library makes changes, so that library changes don't automatically break patron customizations.

Any change to message triggers and borrower messaging preferences is going to require some *very* careful thought; there's a much broader spectrum of use-cases and work flows than meets the eye.