[Koha-bugs] [Bug 20962] Overhaul to notices
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20962 Koha collecto changed: What|Removed |Added CC||k...@collecto.ca -- You are receiving this mail because: You are watching all bug changes. ___ Koha-bugs mailing list Koha-bugs@lists.koha-community.org https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-bugs website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
[Koha-bugs] [Bug 20962] Overhaul to notices
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20962 Marjorie Barry-Vila changed: What|Removed |Added CC||patrick.robitaille@collecto ||.ca -- You are receiving this mail because: You are watching all bug changes. ___ Koha-bugs mailing list Koha-bugs@lists.koha-community.org https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-bugs website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
[Koha-bugs] [Bug 20962] Overhaul to notices
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20962 Michal Denar changed: What|Removed |Added CC||blac...@gmail.com -- You are receiving this mail because: You are watching all bug changes. ___ Koha-bugs mailing list Koha-bugs@lists.koha-community.org https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-bugs website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
[Koha-bugs] [Bug 20962] Overhaul to notices
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20962 Marjorie Barry-Vila changed: What|Removed |Added CC||marjorie.barry-vila@collect ||o.ca -- You are receiving this mail because: You are watching all bug changes. ___ Koha-bugs mailing list Koha-bugs@lists.koha-community.org https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-bugs website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
[Koha-bugs] [Bug 20962] Overhaul to notices
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20962 Katrin Fischer changed: What|Removed |Added See Also||https://bugs.koha-community ||.org/bugzilla3/show_bug.cgi ||?id=21525 -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes. ___ Koha-bugs mailing list Koha-bugs@lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-bugs website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
[Koha-bugs] [Bug 20962] Overhaul to notices
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20962 Barton Chittenden changed: What|Removed |Added See Also||https://bugs.koha-community ||.org/bugzilla3/show_bug.cgi ||?id=21165 -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes. ___ Koha-bugs mailing list Koha-bugs@lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-bugs website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
[Koha-bugs] [Bug 20962] Overhaul to notices
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20962 --- Comment #11 from Barton Chittenden --- (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. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug. ___ Koha-bugs mailing list Koha-bugs@lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-bugs website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
[Koha-bugs] [Bug 20962] Overhaul to notices
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20962 --- Comment #10 from Katrin Fischer --- 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 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. ___ Koha-bugs mailing list Koha-bugs@lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-bugs website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
[Koha-bugs] [Bug 20962] Overhaul to notices
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20962 Joy Nelson changed: What|Removed |Added CC||j...@bywatersolutions.com --- Comment #9 from Joy Nelson --- > > # 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! -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes. ___ Koha-bugs mailing list Koha-bugs@lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-bugs website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
[Koha-bugs] [Bug 20962] Overhaul to notices
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20962 Barton Chittenden changed: What|Removed |Added CC||bar...@bywatersolutions.com --- Comment #8 from Barton Chittenden --- (In reply to Jonathan Druart from comment #5) > 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: <> Detail here Whatever CLAIMSERIAL does. Not all of these fit nicely with -- 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 tags, I would prefer to extend Koha/Template/Plugin to create more user friendly looping constricts in TT, then deprecate <>, , the '' detail, etc. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug. ___ Koha-bugs mailing list Koha-bugs@lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-bugs website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
[Koha-bugs] [Bug 20962] Overhaul to notices
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20962 George Williams (NEKLS) changed: What|Removed |Added CC||geo...@nekls.org --- Comment #7 from George Williams (NEKLS) --- # 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. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug. ___ Koha-bugs mailing list Koha-bugs@lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-bugs website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
[Koha-bugs] [Bug 20962] Overhaul to notices
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20962 --- Comment #6 from Lisette --- (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 -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug. ___ Koha-bugs mailing list Koha-bugs@lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-bugs website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
[Koha-bugs] [Bug 20962] Overhaul to notices
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20962 Lisette changed: What|Removed |Added CC||lisettesla...@gmail.com -- You are receiving this mail because: You are watching all bug changes. ___ Koha-bugs mailing list Koha-bugs@lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-bugs website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
[Koha-bugs] [Bug 20962] Overhaul to notices
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20962 Jonathan Druart changed: What|Removed |Added CC||jonathan.dru...@bugs.koha-c ||ommunity.org --- Comment #5 from Jonathan Druart --- 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). -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes. ___ Koha-bugs mailing list Koha-bugs@lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-bugs website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
[Koha-bugs] [Bug 20962] Overhaul to notices
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20962 --- Comment #4 from Hugh Rundle --- 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. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes. ___ Koha-bugs mailing list Koha-bugs@lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-bugs website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
[Koha-bugs] [Bug 20962] Overhaul to notices
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20962 --- Comment #3 from Katrin Fischer --- 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. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes. ___ Koha-bugs mailing list Koha-bugs@lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-bugs website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
[Koha-bugs] [Bug 20962] Overhaul to notices
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20962 Hugh Rundle changed: What|Removed |Added CC||dani...@brimbank.vic.gov.au --- Comment #2 from Hugh Rundle --- 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. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug. ___ Koha-bugs mailing list Koha-bugs@lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-bugs website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
[Koha-bugs] [Bug 20962] Overhaul to notices
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20962 Katrin Fischer changed: What|Removed |Added CC||katrin.fisc...@bsz-bw.de --- Comment #1 from Katrin Fischer --- 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. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes. ___ Koha-bugs mailing list Koha-bugs@lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-bugs website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
