Hey Guys, I have noticed of late that notifications is in quite a state of disarray. At my library we have had to resort to running queries from a script and manually sending out mail because notifications just don't work in a usable way. I am proposing an overhaul of the notifications system. The only information I have to go on is what my library wants but since we are an academic library that may vary from what the vast majority of Koha wants. Before I made an official wiki for this RFC I wanted to get a general feel for how everyone felt about this. I also wanted to see if someone or a group was willing to pitch in and help me out with some coding. Essentially what I would like to do is model notifications to do the following: 1. Base notification rules on patron type, item type, and a new grouping I am hoping to write that I am calling the collection code 2. Define a frequency for notifications based on the previously stated groupings 3. Base the start time and end time for notifications on the due date rather than the checkout date I am very open to other suggestions and I hope to get some. I know that this idea is far from fully developed. Best, Elliott Davis
2011/8/25 Elliott Davis <tdavis@uttyler.edu>
Hey Guys,****
** **
I have noticed of late that notifications is in quite a state of disarray. At my library we have had to resort to running queries from a script and manually sending out mail because notifications just don’t work in a usable way. I am proposing an overhaul of the notifications system. The only information I have to go on is what my library wants but since we are an academic library that may vary from what the vast majority of Koha wants. Before I made an official wiki for this RFC I wanted to get a general feel for how everyone felt about this. I also wanted to see if someone or a group was willing to pitch in and help me out with some coding.****
** **
Essentially what I would like to do is model notifications to do the following: ****
** **
**1. **Base notification rules on patron type, item type, and a new grouping I am hoping to write that I am calling the collection code
This sounds like it's a bit up in the air at the moment, but how does this relate to the item collection codes that are already in Koha?
****
2. Define a frequency for notifications based on the previously stated groupings
**3. **Base the start time and end time for notifications on the due date rather than the checkout date****
** **
I am very open to other suggestions and I hope to get some. I know that this idea is far from fully developed.****
** **
Best,****
** **
Elliott Davis****
_______________________________________________ Koha-devel mailing list Koha-devel@lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
Everything else sounds good. The notifications backend is pretty good, really, but the UI at least needs some love and updates. -- Jesse Weaver
Jesse, In response to your first question, it will correspond directly to the collection codes that are currently in koha. Essentially what I would like to do is give users another dimension of control when defining overdue rules. For example, If I have 10 items with the collection code of “media” then I would like to set a blanket rule for “media” instead of having to set a rule for each separate item. The thing I really want to get changed on the backend is the 3 notification limit. Currently for our ILL’s we send out notices every day until the end of time or until the book is returned. Let me know if that makes sense or if I am totally crazy. Elliott Davis From: Jesse [mailto:pianohacker@gmail.com] Sent: Thursday, August 25, 2011 2:00 PM To: Elliott Davis Cc: koha-devel@lists.koha-community.org Subject: Re: [Koha-devel] Notifications RFC 2011/8/25 Elliott Davis <tdavis@uttyler.edu<mailto:tdavis@uttyler.edu>> Hey Guys, I have noticed of late that notifications is in quite a state of disarray. At my library we have had to resort to running queries from a script and manually sending out mail because notifications just don’t work in a usable way. I am proposing an overhaul of the notifications system. The only information I have to go on is what my library wants but since we are an academic library that may vary from what the vast majority of Koha wants. Before I made an official wiki for this RFC I wanted to get a general feel for how everyone felt about this. I also wanted to see if someone or a group was willing to pitch in and help me out with some coding. Essentially what I would like to do is model notifications to do the following: 1. Base notification rules on patron type, item type, and a new grouping I am hoping to write that I am calling the collection code This sounds like it's a bit up in the air at the moment, but how does this relate to the item collection codes that are already in Koha? 2. Define a frequency for notifications based on the previously stated groupings 3. Base the start time and end time for notifications on the due date rather than the checkout date I am very open to other suggestions and I hope to get some. I know that this idea is far from fully developed. Best, Elliott Davis _______________________________________________ Koha-devel mailing list Koha-devel@lists.koha-community.org<mailto:Koha-devel@lists.koha-community.org> http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/ Everything else sounds good. The notifications backend is pretty good, really, but the UI at least needs some love and updates. -- Jesse Weaver
On 2011-08-26, at 4:08 AM, Elliott Davis wrote:
Hey Guys,
I have noticed of late that notifications is in quite a state of disarray.
snip
Essentially what I would like to do is model notifications to do the following:
1. Base notification rules on patron type, item type, and a new grouping I am hoping to write that I am calling the collection code 2. Define a frequency for notifications based on the previously stated groupings 3. Base the start time and end time for notifications on the due date rather than the checkout date
fyi, Koha's notifications not doing feature (x,y,z) does not equal 'in quite a state of disarray' last time i looked the code was pretty clean and extendable?
On 2011-08-26, at 3:47 PM, Mason James wrote:
On 2011-08-26, at 4:08 AM, Elliott Davis wrote:
Hey Guys,
I have noticed of late that notifications is in quite a state of disarray.
snip
Essentially what I would like to do is model notifications to do the following:
1. Base notification rules on patron type, item type, and a new grouping I am hoping to write that I am calling the collection code 2. Define a frequency for notifications based on the previously stated groupings 3. Base the start time and end time for notifications on the due date rather than the checkout date
fyi, Koha's notifications not doing feature (x,y,z) does not equal 'in quite a state of disarray'
last time i looked the code was pretty clean and extendable?
ooh, my last comment sounded a little condescending there :/ (friday brain) but hey, my point still stands... the notifications code could be modded to handle your 3 features without to much trouble, i reckon...
Problems I see with Notices: - Overdues are limited to 3 per patron. This needs to be unlimited, so a more robust triggering methodology needs to be put into place, along with tie-ins to fines and privilege restriction - Advance notices are limited to 1 predue and 1 due. - Overdues have two competing syntaxes for item information, <<items.content>> and <item></item>, neither of which are particularly good. - <item/> is only supported in Overdues, not in any of the Advance Notices or Hold notifications - <<items.content>> has to be specified on the commandline, adding sysadmin's to the customization process. - Predue and Due both have separate digest forms, instead of notation that could be flexible enough to handle one or multiple items at a time. - Advance Notices cannot be mandated by the library like Overdues are; what if you want to guarantee your patrons are being sent hold notices? - Overdues cannot be opted into by patrons (I can see no opt-out, but what if you've configured a patron category to not receive overdues, and someone within that category wants to be notified because they're responsible, if a little forgetful?) - Handling of notices to people without email addresses is inconsistent. - For overdues (and possibly advance notices as well) the Koha branch email or admin email are sent the document of all the undeliverable message. - For holds, a completely different HOLD_PRINT notice form is used, as well as a separate script to gather the notices, in HTML, into a directory somewhere on the Koha server. - Overdues and Advance Notices have an HTML option, which works completely differently, but produces the same net effect: notices files on the server - Nothing for checking/checkout notices - Notices are mostly in plain text (except HOLD_PRINT). Should have HTML option, with a WYSIWYG editor. - Message sending is sometimes handled by "process_message_queue", and other times the messages are sent directly - Overdue, Advance and Holds notices are completely incompatible with Hourly Loans at this time - Hold notices are broken out by Branch, Overdues can be too, but Advanced Notices are global. The use of the <<branch>> token has proven quite buggy in my experience - Meaning of "branch" can be unclear in some notice circumstances. Is it the patron's branch? the item's branch? The checkout branch? The currently-logged in branch? Should it follow CircControl? HomeOrHoldingBranch? HomeOrHoldBranchReturn? None? All, in different cases? - SMS is not sufficiently supported; there are character limits that need to be factored in. - Notices do not make use of "reply-to" headers, which would make it much easier for the conversation to continue, without having to fine-tune the mail server settings on the Koha machine to match the addresses of the branch administrators. So, I'm with Elliott. The system needs an overhaul. The difficult now comes with figuring out how to actually accomplish all this in the real world. I recommend: 1. more discussions to nail down a complete specification that meets as many libraries' needs as possible 2. a meeting of the development team (whoever is willing to help) to figure out the core architectural changes required, then allocating work 3. filing separate bugs for each small component, with Depends On and Blocks links. 4. Signoffs and QA on bugs 'in order', that is starting with those that form the baseline of dependencies, then building off them once they're in master. 5. Public test server so that librarians can easily check that the specifications they laid out in the first place are actually met Who's up for the challenge? -Ian On Fri, Aug 26, 2011 at 2:24 AM, Mason James <mtj@kohaaloha.com> wrote:
On 2011-08-26, at 3:47 PM, Mason James wrote:
On 2011-08-26, at 4:08 AM, Elliott Davis wrote:
Hey Guys,
I have noticed of late that notifications is in quite a state of
disarray.
snip
Essentially what I would like to do is model notifications to do the
following:
1. Base notification rules on patron type, item type, and a new
grouping I am hoping to write that I am calling the collection code
2. Define a frequency for notifications based on the previously stated groupings 3. Base the start time and end time for notifications on the due date rather than the checkout date
fyi, Koha's notifications not doing feature (x,y,z) does not equal 'in quite a state of disarray'
last time i looked the code was pretty clean and extendable?
ooh, my last comment sounded a little condescending there :/ (friday brain)
but hey, my point still stands... the notifications code could be modded to handle your 3 features without to much trouble, i reckon... _______________________________________________ Koha-devel mailing list Koha-devel@lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
-- Ian Walls Lead Development Specialist ByWater Solutions Phone # (888) 900-8944 http://bywatersolutions.com ian.walls@bywatersolutions.com Twitter: @sekjal
Le 26/08/2011 14:28, Ian Walls a écrit :
Problems I see with Notices:
* Overdues are limited to 3 per patron. This needs to be unlimited, so a more robust triggering methodology needs to be put into place, along with tie-ins to fines and privilege restriction * Advance notices are limited to 1 predue and 1 due. * Overdues have two competing syntaxes for item information, <<items.content>> and <item></item>, neither of which are particularly good. o <item/> is only supported in Overdues, not in any of the Advance Notices or Hold notifications o <<items.content>> has to be specified on the commandline, adding sysadmin's to the customization process. * Predue and Due both have separate digest forms, instead of notation that could be flexible enough to handle one or multiple items at a time. * Advance Notices cannot be mandated by the library like Overdues are; what if you want to guarantee your patrons are being sent hold notices? * Overdues cannot be opted into by patrons (I can see no opt-out, but what if you've configured a patron category to not receive overdues, and someone within that category wants to be notified because they're responsible, if a little forgetful?) * Handling of notices to people without email addresses is inconsistent. o For overdues (and possibly advance notices as well) the Koha branch email or admin email are sent the document of all the undeliverable message. o For holds, a completely different HOLD_PRINT notice form is used, as well as a separate script to gather the notices, in HTML, into a directory somewhere on the Koha server. o Overdues and Advance Notices have an HTML option, which works completely differently, but produces the same net effect: notices files on the server o Nothing for checking/checkout notices * Notices are mostly in plain text (except HOLD_PRINT). Should have HTML option, with a WYSIWYG editor. * Message sending is sometimes handled by "process_message_queue", and other times the messages are sent directly * Overdue, Advance and Holds notices are completely incompatible with Hourly Loans at this time * Hold notices are broken out by Branch, Overdues can be too, but Advanced Notices are global. The use of the <<branch>> token has proven quite buggy in my experience * Meaning of "branch" can be unclear in some notice circumstances. Is it the patron's branch? the item's branch? The checkout branch? The currently-logged in branch? Should it follow CircControl? HomeOrHoldingBranch? HomeOrHoldBranchReturn? None? All, in different cases? * SMS is not sufficiently supported; there are character limits that need to be factored in. * Notices do not make use of "reply-to" headers, which would make it much easier for the conversation to continue, without having to fine-tune the mail server settings on the Koha machine to match the addresses of the branch administrators.
So, I'm with Elliott. The system needs an overhaul. The difficult now comes with figuring out how to actually accomplish all this in the real world. I recommend:
1. more discussions to nail down a complete specification that meets as many libraries' needs as possible 2. a meeting of the development team (whoever is willing to help) to figure out the core architectural changes required, then allocating work 3. filing separate bugs for each small component, with Depends On and Blocks links. 4. Signoffs and QA on bugs 'in order', that is starting with those that form the baseline of dependencies, then building off them once they're in master. 5. Public test server so that librarians can easily check that the specifications they laid out in the first place are actually met
Who's up for the challenge?
-Ian
Maybe it needs overhaul. But some people already proposed something for that years ago C4::Mailer. It uses C4::Mailer for all the messages and a Template::Toolkit definition for messaging. And tried to assign all the problems of the Notification system. One can see that there : https://github.com/xercode/koha has anyone tested it ? About some of the problems raised by Elliot, it is not only notification system but also issuing rules that would need overhaul... itemtypes, and all that. It would be nice to write some design with as many libraries as possible and not only a few developers... Since those things are impacting Koha as a whole. My 2 cents. -- Henri-Damien LAURENT BibLibre
Another thing that would be nice would be the ability to specify which level of notices to produce (First, Second, Third, etc). I was fiddling around with notices yesterday, and if you produce an html file for them, you can tell which is which because of the differences in the notices template for each level. But if you produce a csv file, you can't tell which is which because it just outputs the data into the file. We have a library that wants to mail their overdue notices, and they're not entirely happy with how the html output prints, and they could use the csv file for mail merge in a word processor, but since it lumps all the levels together, there's no way to tell which level they are. Cheers, Cindy -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Cindy Murdock Ames IT Services Director Meadville Public Library | CCFLS http://meadvillelibrary.org | http://ccfls.org
You should be able to select for that based on the letter_code field, assuming you're using different notice files for each level. For example: select * from message_queue where letter_code = 'ODUE3' order by time_queued desc should produce only third overdue messages. Jane Wagner Senior Project Manager LibLime, a division of PTFS Content Management and Library Solutions 6400 Goldsboro Road, Suite 200 Bethesda, MD 20817 (301) 654-8088 x 151 jwagner@liblime.com -----Original Message----- From: koha-devel-bounces@lists.koha-community.org [mailto:koha-devel-bounces@lists.koha-community.org] On Behalf Of Cindy Murdock Ames Sent: Friday, August 26, 2011 10:57 AM To: koha-devel@lists.koha-community.org Subject: Re: [Koha-devel] Notifications RFC Another thing that would be nice would be the ability to specify which level of notices to produce (First, Second, Third, etc). I was fiddling around with notices yesterday, and if you produce an html file for them, you can tell which is which because of the differences in the notices template for each level. But if you produce a csv file, you can't tell which is which because it just outputs the data into the file. We have a library that wants to mail their overdue notices, and they're not entirely happy with how the html output prints, and they could use the csv file for mail merge in a word processor, but since it lumps all the levels together, there's no way to tell which level they are. Cheers, Cindy -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Cindy Murdock Ames IT Services Director Meadville Public Library | CCFLS http://meadvillelibrary.org | http://ccfls.org _______________________________________________ Koha-devel mailing list Koha-devel@lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
participants (7)
-
Cindy Murdock Ames -
Elliott Davis -
Ian Walls -
Jesse -
LAURENT Henri-Damien -
Mason James -
Wagner, Jane