RT-EMAI...SHBOARDS(1)

πŸ“¦
version 5.0.10 Β· 4 versions
, in fedora 43

πŸ‘‘ rt-email-dashboards β€” the manual, but make it cute

ok so first thing, bestie: this is the rt-email-dashboards page from the User Contributed Perl Documentation collection, and I'm gonna walk you through it like we're texting at 2am. grab a snack. πŸ“


✨ NAME ✨

rt-email-dashboards β€” it sends email dashboards. that's it, that's the whole job. πŸ’Œ


🌸 SYNOPSIS 🌸

rt-email-dashboards [options]

πŸ’… DESCRIPTION πŸ’…

okay so here's the vibe: this tool slides into your users' inboxes based on how they've subscribed to dashboards. and what's a dashboard? it's a set of saved searches. the subscription is what controls how often that dashboard gets sent out and how it's displayed. dashboard = the content, subscription = the schedule + the glow-up. ✨

every subscription has an hour, and possibly a day of week or a day of month. and the timezone tea? those values are taken to be in the user's timezone if available, and UTC otherwise. no timezone? UTC. sorry babe, those are the rules. 🌍


πŸŽ€ SETUP πŸŽ€

you're gonna need cron running this script every hour. no cap. here's an example crontab entry that does exactly that:

0 * * * * /usr/bin/rt-email-dashboards

this runs the script every hour on the hour. πŸ• it may need some further tweaking to be run as the correct user β€” so like, double-check who you're running as, bestie.


πŸ”₯ OPTIONS πŸ”₯

this tool supports a few options. most of them are for debugging, which is giving dev-mode main character energy. πŸ› οΈ

  • -h, --help β€” display this documentation. read the docs, queen. πŸ“–
  • --dryrun β€” figure out which dashboards would be sent, but don't actually generate or email any of them. it's the dress rehearsal, not the performance. πŸ™ˆ
  • --dashboards DASHBOARD_IDS β€” only check specified dashboards (comma-separated IDs).
  • --time SECONDS β€” instead of using the current time to figure out which dashboards should be sent, use SECONDS. and usually that's since midnight Jan 1st, 1970, so like, 1192216018 would be Oct 12 19:06:58 GMT 2007. time travel but make it unix. ⏳
  • --epoch SECONDS β€” backwards-compatible for --time SECONDS. it's the same thing wearing a vintage jacket. πŸ’œ
  • --all β€” ignore subscription frequency when considering each dashboard. ⚠️ heads up: this should only be used with --dryrun for testing and debugging. do not freestyle this one in prod, bestie, I'm begging.
  • --user User NAME or ID β€” only check the specified user's subscriptions.
  • --recipient User NAME or EMAIL or ID β€” only send emails to the specified user. can be specified multiple times to send multiple emails, like:
--recipient alice@example.com --recipient bob@example.com

this is mostly useful for testing, especially dashboard issues seen only by a specific user. for typical dashboard emails, set recipients via the subscription settings in the web UI. (i.e. this is your debugging scalpel, not your everyday workflow. 🩺)

  • --log LEVEL β€” adjust LogToSTDERR config option.
  • --statement-log LEVEL β€” log any SQL queries produced at the specified log level. this works similar to the $StatementLog option in the main RT config file. πŸ—„οΈ

πŸ’– quick recap so it's locked in your brain forever: dashboards get emailed on their subscription schedule (user timezone if available, UTC otherwise), you need cron hitting it every hour, and like half of these options are just for debugging. iconic behavior honestly.

and that's the whole page, babe β€” written by the User Contributed Perl Documentation girlies, running on perl v5.42.3, dated 2026-07-20. go forth and schedule those dashboards. periodt. πŸ’…πŸ¦‹πŸŒΈ

πŸ“¦ where this page comes from