1 of 1 people found this helpful
Yeah, I understand--it's a lot of options and capabilities. The advantage to using the workbook to configure things rather than the YAML file is that you have far, far, greater flexibility and control than you would have had with just the YAML. And more visibility into what alerts exist, and how VizAlerts processes them.
But worry not, there are really only a few things you need to set out of the box, especially if you're just testing things out. The standard defaults will be fine for everything else.
Set the parameter values properly for the just the following two:
Where each says "yourcompany", just put in your own company domain. So for example, I work at Tableau, so all our email addresses are "tableau.com". That means that I should have:
The first means "users may only email addresses ending in "tableau.com"--so only internal mail is allowed. The second means "all email sent from vizalerts can only have a 'from' address ending in 'tableau.com'". So, an alert author can send an email that appears to come from any address at tableau.com, but nothing else. You could restrict things further by setting it to something like 'vizalerts@tableau\.com', which would mean they couldn't spoof any from addresses--they'd only be able to send mail using VizAlerts as the from address.
Setting these two values as your defaults will get you started. If you decide to roll things out in a bigger way, you may want to tweak the global defaults, or loosen restrictions on your own vizalerts, or those of particularly trustworthy/skilled alert authors. Editing the calculations would enable you to override your parameter-defined defaults on a case-by-case basis. But you really don't need to worry about that at this point.
Hope that helps.
2 of 2 people found this helpful
Thanks for the questions! Let me first write that when Matt put forth this idea I didn't get it either, the yaml file was straightforward to me and adding a viz to the config along with the yaml just seemed liked an added complexity. After a conversation or two (or three, sometimes I'm slow) with Matt the lightbulb finally went on for me and I could understand the genius of the idea. Here's the best summary I've got right now, if you can poke holes in it or improve on it, we welcome your feedback!
The VizAlerts .yaml file sets the minimum needed configuration options to get the VizAlerts Python code up and running, things like the Tableau Server location, and SMTP server location are stored there. The VizAlerts ScheduledTriggerView viz then has a lot more configuration options such as whether emails and/or SMS can be sent, what's allowed for destination email addresses and SMS numbers, etc. and ultimately these options are configurable for each Simple Alert and each trigger view for Advanced Alerts. Essentially every option that we've learned or heard that VizAlerts admins might want to change and/or make conditional on a per schedule, per trigger view, per workbook, per project, and/or per user basis is available in the VizAlerts ScheduledTriggerView viz, and we're using a Tableau viz because then we get access to the flexibility of Tableau calculated fields, data blends, and/or cross-database joins to build out those conditions.
For example in the ScheduledTriggerView viz we could set up a condition like "Jeannie in Marketing can send alerts to any email address but Johan in Finance can only send emails inside the company" or "only workbooks in the Ok-for-client-distribution project can be sent outside the company". Or we can set set different timeout thresholds for different schedules so a schedule that is run once per month has a long timeout while schedules that are run once per hour have shorter timeouts. Another use case is a workaround for a current limitation for Tableau where there are no permissions on Schedules -- effectively anyone can subscribe any view to any Schedule. Using VizAlerts and the ScheduledTriggerView viz we can create conditions where only certain users or views are able to be subscribed to high-volume schedules. For example Jimmy-the-nervous-guy-in-Sales won't be using up resources getting an update every 15 minutes on whether he's meeting monthly targets because we can set up a filter in the ScheduledTriggerView viz to block those. And, to get really meta and close the loop, we can even use the data source behind the ScheduledTriggerView viz as a source for alerts that would tell subscribers that they subscribed to a Schedule that they're not supposed to use or otherwise have some limiting condition. So Jimmy-the-nervous-guy-in-Sales can instead get a polite email that he can subscribe to the daily schedule like everyone else.
Now for a bit more on why these options are in a Tableau viz and not in the yaml file. One additional factor is that with adding SMS messaging in VizAlerts 2.0 (and we got close to adding file export as an action, we're planning on that for 2.1) we were really clear that we needed to enable VizAlerts admins to have fine-grained controls over who could do what and when. Using the Jimmy-the-nervous-guy-in-Sales example, we knew VizAlerts admins wouldn't want him to be able to rack up a bunch of SMS charges to the company by sending himself text messages every 15 minutes on his progress towards quota. The more advanced conditions like the ones I've described here weren't really feasible to set up as options in a yaml file, the only way VizAlerts 1.x supported these was by editing the SQL code at the bottom of the yaml file which a) was more challenging because there wasn't a VizAlerts interface to run and validate the SQL and b) even more difficult for some admins because there are a number of prospective and actual VizAlerts admins who don't know SQL (and we don't believe they should have to know SQL to get their jobs done). So the change in VizAlerts 2.0 moves the SQL to the background as a data source and now we build out those conditions using Tableau itself. Which, I admit, isn't always that easy to set up!
How's that for a more detailed explanation (I'm sort of drafting it here for the next iteration of the VizAlerts documentation)?
Now that was just well-said! Thanks for writing all that up, Jonathan.
Wow.... Matt and Jonathan!! That's some serious service here, thank you
thank you. After Jonathan's elaborate and well thought out reply, I'd be a
horrible person not to give this pup a try and configure it.
I was hesitant to even ask the question for the fear of asking stupid
questions, but your willingness to help is humbling and encouraging. You
guys rock! Ok, I now have some work to do here, I'll start mucking with it
tomorrow. I will probably come back to you guys if I may, in the event I
get stuck. Thank you again!
On Thu, Dec 1, 2016 at 6:53 PM Jonathan Drummey <
Good morning. A couple of items that came up during the config of the workbook and the simple testing process:
1. the python vizalerts.py command yielded this error:
2. The option to "Show Parameter" for any / all parameters in the workbook are grayed out. I cannot bring them into the view / analysis to make any modifications to the default value or any other values.
3. After publishing the workbook to the server, the ScheduledTriggerViews sheet is still blank. If there is data to be displayed, it is not being displayed. I can only see the parameters you have built into the sheet by default.
I can quickly answer #1 and #3, I’ll leave #2 for Matt.
- For #1 the Python module hasn’t been installed, you’ll need to run the following commands:
pip install twilio
pip install phonenumberslite
- For #3 the view is blank because there are no Tableau views that have been subscribed to a VizAlerts schedule (i.e. one of the special disabled schedules for VizAlerts).
Yup, correct on #1. Comment on #3 makes sense. TY.
running the .py script again gave me -1 return for Trusted Ticket and "An Unhandled exception occurred: Traceback" error. I'll take a look at the logs to see what's causing the trusted ticket error and I think there's something on this website / kb for the Traceback error. I will report back shortly.
For #2, you can right-click any of the parameters in the Parameters pane on the bottom left and pick "Edit". If you want to hide one or more of the parameter controls from the viz, go to the control, click the down arrow on upper right, and select "Hide Card". You can't show the parameter control if it's already shown, that's my that setting is grayed out for all of them except the png height/width settings (which frankly I don't think are that useful).
You're right, of course. I can right click and 'edit'. I wanted to change the SMS default settings (1 to 0) and I can only do that via the 'edit' even though it's not already in the viz. But yes, I can still control that parameter and manually change it to 0 via the 'edit' option. TY.
There will be some info in the vizql-*.log files despite the lack of a timestamp. If we get a "-1" back it means that Tableau Server received the request and decided that it wasn't valid. So search those vizql files again for the "TrustedTicketServiceImpl" string from the bottom up, and you should find out what the problem is.