I have been trying to track down why I am still getting subscription emails for a dashboard for which I thought I had disabled my subscription.
When I go to Tools → Dashboards, there is a dashboard defined at the group level for a group that I belong to. Previously, I was subscribed to this dashboard daily at 6am. I since went back in to try to disable it, and the subscription column now reads “None”. I click on None and it shows that the subscription frequency is “never”. Yet, I still get the subscription email every morning at 6am as it was previously set to do.
Our RT 3.8.8 install has only this one dashboard defined. I did some exploring directly in the database, and in the Attributes table there is only one row for a subscription, and when I resubmit the “never” frequency for this subscription, that row gets hit (lastUpdated becomes current time). Yet, I am still getting the email.
Is this a bug, or is there some other way to subscribe to dashboards that I need to disable? What would happen if I simply delete this row from the DB (seems like a bad idea, but might work)?
Fran Fabrizio
Director of Information Systems
UAB College of Arts and Sciences
HHB560C | 205.996.5698 | fabrizio@uab.edu
I have been trying to track down why I am still getting subscription emails for a dashboard for which I thought I had disabled my subscription.
When I go to Tools → Dashboards, there is a dashboard defined at the group level for a group that I belong to. Previously, I was subscribed to this dashboard daily at 6am. I since went back in to try to disable it, and the subscription column now reads “None”. I click on None and it shows that the subscription frequency is “never”. Yet, I still get the subscription email every morning at 6am as it was previously set to do.
Our RT 3.8.8 install has only this one dashboard defined. I did some exploring directly in the database, and in the Attributes table there is only one row for a subscription, and when I resubmit the “never” frequency for this subscription, that row gets hit (lastUpdated becomes current time). Yet, I am still getting the email.
Is this a bug, or is there some other way to subscribe to dashboards that I need to disable? What would happen if I simply delete this row from the DB (seems like a bad idea, but might work)?
use sbin/rt-attributes-viewer to look at that attribute record and see
what is in it.
-kevin
use sbin/rt-attributes-viewer to look at that attribute record and see
what is in it.
Just as an aside, that script wasn’t in my 3.8.8 install. (Probably related to: Re: [rt-users] Reset User's Search Format?) Grabbed a fresh tarball to get it and ran it.
Content of attribute #91: $VAR1 = {
‘ContentType’ => ‘storable’,
‘Content’ => {
‘Frequency’ => ‘never’,
‘Recipient’ => ‘’,
‘DashboardId’ => ‘70’,
‘Hour’ => ‘06:00’,
‘Dom’ => ‘1’,
‘Rows’ => ‘0’,
‘Fow’ => ‘1’,
‘Counter’ => 24,
‘Dow’ => ‘Monday’
},
‘Description’ => ‘Subscription to dashboard 70’,
‘Name’ => ‘Subscription’,
‘ObjectId’ => ‘52’,
‘ObjectType’ => ‘RT::User’
};
use sbin/rt-attributes-viewer to look at that attribute record and see
what is in it.
Just as an aside, that script wasn’t in my 3.8.8 install. (Probably
related to:
Re: [rt-users] Reset User's Search Format?)
Grabbed a fresh tarball to get it and ran it.
Mm, yes, I’d forgotten about that mispackaging
'Name' => 'Subscription',
Just to confirm, this is the only thing turned up by
Select * from Attributes where Name = ‘Subscription’;
-kevin
Content of attribute #91: $VAR1 = {
‘ContentType’ => ‘storable’,
‘Content’ => {
‘Frequency’ => ‘never’,
‘Recipient’ => ‘’,
‘DashboardId’ => ‘70’,
‘Hour’ => ‘06:00’,
‘Dom’ => ‘1’,
‘Rows’ => ‘0’,
‘Fow’ => ‘1’,
‘Counter’ => 24,
‘Dow’ => ‘Monday’
},
‘Description’ => ‘Subscription to dashboard 70’,
‘Name’ => ‘Subscription’,
‘ObjectId’ => ‘52’,
‘ObjectType’ => ‘RT::User’
};
That looks correct, rt-email-dashboards should be skipping the
subscription if the frequency is “never”. Hm. Can you produce the
crontab entry for rt-email-dashboards? Perhaps it mistakenly has --all
in its options, which always issues mail for dashboard subscriptions
regardless of their frequency.
Shawn
To first answer Kevin’s question, yep that’s the only record that is returned when doing select * from Attributes where Name = ‘Subscription’;
The crontab entry is:
0 * * * * /usr/local/rt/sbin/rt-email-dashboards
Thanks,
Fran
To first answer Kevin’s question, yep that’s the only record that is returned when doing select * from Attributes where Name = ‘Subscription’;
The crontab entry is:
0 * * * * /usr/local/rt/sbin/rt-email-dashboards
Thanks,
Fran
Can you turn up your log level to debug and run
/usr/local/rt/sbin/rt-email-dashboards with the --time argument needed
to hit your 6am dashboard time? You can figure out the right argument
with this script, replacing America/New_York with your time zone:
perl -MDateTime -e ‘print DateTime->now(time_zone =>
“America/New_York”)->set_hour(6)->set_time_zone(“UTC”)->epoch’
Shawn
I ran the following command (figured out you meant --epoch, not --time 
/usr/local/rt/sbin/rt-email-dashboards --debug --epoch 1292849980
Using time Mon Dec 20 06:59:40 2010
Sending email from helpdesk@cas.uab.edu
[snip other users]
Checking fabrizio’s subscriptions: hour 06:00, dow Monday, dom 20
Checking against subscription with frequency never, hour 06:00, dow Monday, dom 1
[snip other users]
I could not trick it into sending the subscription. However, it did send it to me at 6am this morning, as it has been every morning.
I notice that the debug output seems to think the subscription is only for “dom 1”. Yet I still get it every morning.
-Fran
I ran the following command (figured out you meant --epoch, not --time
My bad. Internally the code uses “time” instead of “epoch”.
/usr/local/rt/sbin/rt-email-dashboards --debug --epoch 1292849980
Using time Mon Dec 20 06:59:40 2010
Sending email from helpdesk@cas.uab.edu
[snip other users]
Checking fabrizio’s subscriptions: hour 06:00, dow Monday, dom 20
Checking against subscription with frequency never, hour 06:00, dow Monday, dom 1
[snip other users]
I could not trick it into sending the subscription. However, it did send it to me at 6am this morning, as it has been every morning.
I notice that the debug output seems to think the subscription is only for “dom 1”. Yet I still get it every morning.
The dow and dom attributes only apply when the subscription is weekly or
monthly. But your subscription is “never” so they don’t apply.
I’m especially stumped now that you can’t get it to send you mail even
though you’re running rt-email-dashboards manually. Can you change your
subscription in RT – especially the hour – to see if that affects the
dashboard mail you shouldn’t be getting?
Are you comfortable with forwarding me personally a copy of the
dashboard email (sartak@bestpractical.com) after removing identifying
information?
Thanks,
Shawn
I changed the subscription time to 7am (keeping the frequency at never), and still got the mail… at 6am!
All signs point to you having another subscription (though we seem to
have ruled that out) or, like Ken Crocker guessed, a second RT instance
(or just rt-send-dashboards cronjob) running.
Not sure what to tell you, unfortunately. I don’t see any way these
symptoms could be caused by an ordinary bug in the dashboard code.
If you do figure it out please follow up because I’m curious and would
like to better diagnose this situation in the future. This thread has
already prompted some improvements to dashboard diagnostics, so thanks.
Shawn
Found it finally!
2nd instance.
Haha, I’m glad the problem ended up being something that was not
actually impossible.
My successor at my former job here accidentally fired up our old VM some weeks ago. Because of the way the mail flows around here and the DNS setup, it was not immediately obvious that the mail was originating from a different server. The clue that tipped me off to it was that when I looked deeper at the report, it showed one ticket still owned by someone who no longer works here. I knew I reassigned all of his tickets elsewhere, so it was then obvious that this was pulling from stale data. I should have caught this much sooner, but it was a “can’t see the forest for the trees” problem.
Thanks for all your help. At least the effort uncovered some other opportunities for improvement.
-Fran
Shawn