Bug 2434

Summary: Remove unimplemented upcoming events message
Product: Koha Reporter: Nicole C. Engard <nengard>
Component: NoticesAssignee: Nicole C. Engard <nengard>
Status: CLOSED FIXED QA Contact: Bugs List <koha-bugs>
Severity: normal    
Priority: PATCH-Sent (DO NOT USE) CC: chris, gmcharlt, jwagner, ztajoli
Version: master   
Hardware: PC   
OS: All   
Change sponsored?: --- Patch complexity: ---
Documentation contact: Documentation submission:
Text to go in the release notes:
Version(s) released in:
Bug Depends on:    
Bug Blocks: 26985    
Attachments: patch
updated patch
messaging on an indiv patron in staff
messaging on an indiv patron in opac
Screen shot of staff patron record editing message settings
Screen shot of OPAC patron record editing message settings
Screen shot of messaging settings in patron category setup
follow up patch
Screen shot after manual deletion of message transport entries

Description Chris Cormack 2010-05-21 00:51:08 UTC


---- Reported by nengard@gmail.com 2008-07-30 13:18:55 ----

[15:09]  <emilyfunk> Hi, thanks. first question: upcoming events - Can you set up a notice in the notice module for upcoming events? where is the info generated for this feature?
[15:11]  <acmoore> that's actually pretty unimplemented. The idea was for OCLS to provide us a list of upcoming library classes and we would run it against those people who wanted notices about them. But, we never got any data about that. So, as it is nothing sends poeople those notices.
[15:12]  <nengard> acmoore is it possible to remove the unimplemented tabs for now?  they're confusing to users
[15:12]  <nengard> tabs = columns
[15:13]  <emilyfunk> yeah, I had some folks get really excited about these new features
[15:13]  <emilyfunk> :/
[15:14]  <acmoore> nengard: sure. open a bug for that. I'd prefer, though, to write the thing that sends the notices, but I don't really know how to do that now.



---- Additional Comments From adrea@moablibrary.org 2009-03-10 13:58:46 ----

Our library would also like to see the "Upcoming Events" enhanced messaging column deleted, since it is not implemented.  We think it is bad customer service to allow patrons to think that they are opting in to something that doesn't work.



---- Additional Comments From oleonard@myacpl.org 2009-03-11 06:16:05 ----

Looks like the display of that row comes directly from a line in the
message_attributes table. Pending a global fix, I'm guessing one could simply
delete this row from the table.



---- Additional Comments From nengard@gmail.com 2009-06-19 17:12:48 ----

Just wanted to check on the status of this - is there a reason this row is still visible?



---- Additional Comments From bchurch@ptfs.com 2009-07-29 17:56:40 ----

Ideally it would be very helpful if libraries could control which enhanced messages are offered to patrons in OPAC.  Since this is a different issue I will add an enhancement request.



---- Additional Comments From adrea@moablibrary.org 2009-07-29 21:06:06 ----

We had a patron opt into the Upcoming Events message settings online and then asking me why they never get any emails about events.  In the meantime, until this unimplemented messaging option is deleted, could someone pst an sql report which will give me a list of patrons who have opted in to Upcoming Event messages?  Then I can add them to our separate library news email list which actually works.  Thanks!



---- Additional Comments From jwagner@ptfs.com 2009-07-30 11:51:33 ----

I've been troubled by the whole messaging option in the OPAC for a while.  I think there should be options to control (a) whether the messaging tab is visible at all (I had to brute-force a screen change to disable it) and (b) an option to turn on/off each individual messaging setting.  The library should be able to control what is available for patron use.



---- Additional Comments From nengard@gmail.com 2009-07-30 12:06:29 ----

This used to be controlled by the EnhancedMessagingPreferences system preference - is it not anymore?



---- Additional Comments From jwagner@ptfs.com 2009-07-30 12:12:41 ----

Nicole, the problem with using EnhancedMessagingPreferences is that it must be on for hold alert emails to work (which is usually a requirement).  However, if it's on, then all the other messaging stuff shows up both in staff and patron mode.  It's all-or-nothing, and it shouldn't be.  Display options should be separated out so that libraries can use the hold alerts without turning on everything else.




---- Additional Comments From nengard@gmail.com 2009-07-30 12:24:31 ----

I agree - was just checking to make sure there wasn't another bug that needed reporting.  

I'm with everyone else on this - I would love to see each messaging option set to a toggle so that librarians can pick and choose which messages they want patrons to choose from.



--- Bug imported by chris@bigballofwax.co.nz 2010-05-21 00:51 UTC  ---

This bug was previously known as _bug_ 2434 at http://bugs.koha.org/cgi-bin/bugzilla3/show_bug.cgi?id=2434

Actual time not defined. Setting to 0.0
CC member adrea@moablibrary.org does not have an account here
CC member bchurch@ptfs.com does not have an account here
CC member emily.funk@liblime.com does not have an account here
CC member jwagner@ptfs.com does not have an account here
CC member rch@liblime.com does not have an account here

Comment 1 Nicole C. Engard 2010-06-04 14:52:13 UTC Comment hidden (obsolete)
Comment 2 Nicole C. Engard 2010-06-05 15:36:36 UTC
Created attachment 2222 [details] [review]
updated patch
Comment 3 Nicole C. Engard 2010-06-05 15:37:05 UTC
Comment on attachment 2222 [details] [review]
updated patch

[11:14]  <cait> nengard: around?
[11:14]  <nengard> yes
[11:14]  <cait> i saw you patch yesterday, but you were already gone. - can you perhaps delete the message option in gemran files too?
[11:15]  <nengard> oops - yup, sure can
[11:15]  <cait> not to speak about the other langauges, but would save me another database update :)
[11:15]  <cait> I think not many people thingk about the other languages :( I get a feeling it will get hard to keep them in sync
[11:16]  <cait> thanks a lot! 
[11:17]  <nengard> i actually did check them with a previous patch (I forget which one) but something was different so i assumed they were always different ... 
[11:17]  <nengard> anyway, this is no problem
[11:18]  <cait> some files aren't even translated and im not sure all languages really work for installation
[11:18]  <cait> German does :)
[11:20]  <cait> thx again! nengard++
[11:20]  <nengard> np
[11:28]  <nengard> i remember why i stopped editing other languages now ...
[11:28]  <nengard> fatal: 0001-bug-2434-remove-upcoming-events-for-all-languages.patch: 112: patch contains a line longer than 998 characters
[11:28]  * braedon|home has quit (Quit: Leaving.)
[11:28]  <nengard> one of the files has a line that is too long ... off to hunt it down
[11:32]  <cait> oh
[11:34]  <nengard> oh crap i can't remove it ... it's a line i already edited so it's the line of the patch that is showing the line i removed .... okay emailing the patch as an attachment
Comment 4 Zeno Tajoli 2010-06-21 15:06:53 UTC
This bug is present also in 3.0.x version.
In the linked mail there is the patch for italian version of notices.sql.

The link is: 
http://lists.koha-community.org/pipermail/koha-patches/2010-June/012121.html
Comment 5 Galen Charlton 2010-06-25 09:44:55 UTC
Pushed patch removing the events message type.  Please test and close.
Comment 6 Jane Wagner 2010-06-25 12:43:20 UTC
The line for Upcoming Events still is gone in patron category messaging setup, but still shows in staff mode on individual patron records, and in the OPAC My Messaging tab. Those need to be removed as well.  It seems to be getting the line from C4/Form/MessagingPreferences.pm, which is looking at the message_transports table:

        foreach my $transport ( @{$pref->{'transports'}} ) {
            $option->{'transport-'.$transport} = 'checked="checked"';
        }
        $option->{'digest'} = 'checked="checked"' if $pref->{'wants_digest'};
    }
    $template->param(messaging_preferences => $messaging_options);

So does this mean that each site must remove that line from the transports table to get rid of it?  Is this something that could be scripted as a patch?

On my 3.2 test server, as delivered there are two lines in that table that seem to be relevant:

message_attribute_id	message_transport_type	is_digest	letter_module	letter_code
3	email	0	circulation	EVENT
3	sms	0	circulation	EVENT


It looks like the EVENT notice file should also be removed.
Comment 7 Nicole C. Engard 2010-06-29 13:45:08 UTC
I do not see that line in any of the pages you mentioned ... can you provide URLs and screenshots please?
Comment 8 Nicole C. Engard 2010-06-29 13:45:29 UTC
Created attachment 2282 [details]
messaging on an indiv patron in staff
Comment 9 Nicole C. Engard 2010-06-29 13:46:07 UTC
Created attachment 2283 [details]
messaging on an indiv patron in opac

This does not show the event line anymore...
Comment 10 Nicole C. Engard 2010-06-29 13:46:17 UTC
Comment on attachment 2282 [details]
messaging on an indiv patron in staff

This does not show the event line anymore...
Comment 11 Jane Wagner 2010-06-29 13:54:18 UTC
Created attachment 2284 [details]
Screen shot of staff patron record editing message settings

This is from a 3.2 server updated to current head as of today.
Comment 12 Jane Wagner 2010-06-29 13:55:05 UTC
Created attachment 2285 [details]
Screen shot of OPAC patron record editing message settings

This is from a 3.2 server updated to current head as of today.
Comment 13 Jane Wagner 2010-06-29 13:55:53 UTC
Created attachment 2286 [details]
Screen shot of messaging settings in patron category setup

This is from a 3.2 server updated to current head as of today.
Comment 14 Nicole C. Engard 2010-06-29 14:01:41 UTC
This is my transports table ... I don't have those rows you're seeing...


mysql> select * from message_transports;
+----------------------+------------------------+-----------+---------------+-------------+
| message_attribute_id | message_transport_type | is_digest | letter_module | letter_code |
+----------------------+------------------------+-----------+---------------+-------------+
|                    5 | email                  |         0 | circulation   | CHECKIN     | 
|                    5 | sms                    |         0 | circulation   | CHECKIN     | 
|                    6 | email                  |         0 | circulation   | CHECKOUT    | 
|                    6 | sms                    |         0 | circulation   | CHECKOUT    | 
|                    1 | email                  |         0 | circulation   | DUE         | 
|                    1 | sms                    |         0 | circulation   | DUE         | 
|                    1 | email                  |         1 | circulation   | DUEDGST     | 
|                    1 | sms                    |         1 | circulation   | DUEDGST     | 
|                    2 | email                  |         0 | circulation   | PREDUE      | 
|                    2 | sms                    |         0 | circulation   | PREDUE      | 
|                    2 | email                  |         1 | circulation   | PREDUEDGST  | 
|                    2 | sms                    |         1 | circulation   | PREDUEDGST  | 
|                    4 | email                  |         0 | reserves      | HOLD        | 
|                    4 | sms                    |         0 | reserves      | HOLD        | 
+----------------------+------------------------+-----------+---------------+-------------+
14 rows in set (0.00 sec)
Comment 15 Nicole C. Engard 2010-06-29 14:23:34 UTC
Created attachment 2287 [details]
follow up patch

This patch removes EVENT from the transports table for all languages
Comment 16 Galen Charlton 2010-07-01 23:39:09 UTC
Pushed follow-up patch.
Comment 17 Nicole C. Engard 2010-07-03 13:17:24 UTC
Jane, can you test since it worked for me after my first patch?
Comment 18 Jane Wagner 2010-07-06 12:20:32 UTC
I updated my 3.2 test server, but I'm still seeing the Upcoming Events entries in my message transports table.  The EVENT notice file is also still there.
Comment 19 Jane Wagner 2010-07-06 12:40:14 UTC
Per Nicole's request on the IRC, I ran the delete command from the update manually.  It removed the entries from the transports table, but not from the display.  See screen shot for current display.
Comment 20 Jane Wagner 2010-07-06 12:40:48 UTC
Created attachment 2311 [details]
Screen shot after manual deletion of message transport entries
Comment 21 Nicole C. Engard 2010-12-16 21:30:31 UTC
I no longer see it on new installs or my upgrade ... does anyone else think this needs to remain open?
Comment 22 Zeno Tajoli 2010-12-23 11:43:53 UTC
For me (italian setup) this bug is not more present.
It can be close