VizAlerts
VizAlerts copied to clipboard
tableau
Allow non-owners to drive VizAlert execution
Some situations require that someone besides the owner of a workbook have the ability to execute a test, or retry, of a VizAlert. If issues arise while the owner is on vacation, for example, it can be pretty onerous to change the owner of the workbook (potentially even needing to republish), then trigger or reschedule the alert.
Another scenario where this might be helpful is in using a service account to drive the Subscription. That allows for a team to share credentials to access the account, and turn the alert on/off as necessary. I suppose that the service account should really also be the publisher (and therefore the owner) of the workbook in question, too, but requiring that could make re-publishing onerous.
Finally, the main reason we wanted to restrict the subscriptions to the Owner in the first place is so that some random user couldn't come along and trigger the alert you built, without understanding what it does. Maybe we should re-think this, especially with the Smart Defaults feature coming out that will let you leave off the To, From, and other recip fields. Maybe the author wants to build an alert that allows for users to opt-in to receive it, but they still want to customize the content? Subject, body, etc? That might make sense. So in that case, would we fail the alert only when the To, CC, or BCC have been edited? Need to think about that more.
see https://community.tableau.com/thread/243033
Another instance of this request:
https://community.tableau.com/message/664687
Here's a thought on this so we don't have to do something with test_alert and permissions:
- Have a VizAlerts admin (and others that have permissions) viz that lists the alert subscriptions with a unique ID (perhaps based on the subscription ID in Postgres)? 2a. If a user enters a comment in that particular viz that is just the number of that subscription ID then VizAlerts will run the alert at the next opportunity. 2b. Alternatively a VizAlerts admin could run vizalerts.py --alert 42 where the --alert is a command line option to manually run an alert and 42 would be the ID from step 1.
Jonathan
We now have two people creating VizAlerts with different sheets in the same trigger workbook and this is a recurring problem...Another option would be to have a whitelist of users who can trigger advanced alerts for a given view in the VizAlerts config?
I'm considering just removing this restriction entirely. The author can always prevent others from creating subscriptions to their workbook by using Tableau Server permissions to do so. Same with adding a comment. It would require some more thoughtfulness on the part of the owner, and potentially require custom permissions on the different sheets of the view, but I lean towards this approach, since I think it would be simplest to implement and easiest to understand.
Another approach we could take that would solve for the "no backup owner" problem is just allowing the owner of the immediate project the VizAlert lives in to trigger the alert as well. It at least gives the organization one other person who could be a backup. If they're the same person, it doesn't really help though.
I kind of prefer we not put a whitelist in the config viz, because I'd prefer the admin not need to be making changes for people all the time.
What do you think about the first two ideas?
Simple and easy is my answer. If the end result can be done via permissions then so be it. If the application tries to be everything for everyone then it will become more unwieldly to maintain.
Allowing the Project Owner…even the Project Leader…the innate ability to trigger VizAlerts makes sense to me, so I agree with having that option.
I agree with Matt about NOT having a whitelist.
I like removing the restriction and using Tableau Server permissions the best, it makes sense given the general goal of “VizAlerts leverages as much Tableau functionality as possible” .
Jonathan
On May 25, 2018, at 11:22 AM, AirCooledNut <[email protected] mailto:[email protected]> wrote:
Simple and easy is my answer. If the end result can be done via permissions then so be it. If the application tries to be everything for everyone then it will become more unwieldly to maintain.
Allowing the Project Owner…even the Project Leader…the innate ability to trigger VizAlerts makes sense to me, so I agree with having that option.
I agree with Matt about NOT having a whitelist.
From: Matt [mailto:[email protected] mailto:[email protected]] Sent: Friday, May 25, 2018 7:59 AM To: tableau/VizAlerts <[email protected] mailto:[email protected]> Cc: Erkson, Toby (164) <[email protected] mailto:[email protected]>; Comment <[email protected] mailto:[email protected]> Subject: Re: [tableau/VizAlerts] Allow non-owners to drive VizAlert execution (#119)
I'm considering just removing this restriction entirely. The author can always prevent others from creating subscriptions to their workbook by using Tableau Server permissions to do so. Same with adding a comment. It would require some more thoughtfulness on the part of the owner, and potentially require custom permissions on the different sheets of the view, but I lean towards this approach, since I think it would be simplest to implement and easiest to understand.
Another approach we could take that would solve for the "no backup owner" problem is just allowing the owner of the immediate project the VizAlert lives in to trigger the alert as well. It at least gives the organization one other person who could be a backup. If they're the same person, it doesn't really help though.
I kind of prefer we not put a whitelist in the config viz, because I'd prefer the admin not need to be making changes for people all the time.
What do you think about the first two ideas?
— You are receiving this because you commented. Reply to this email directly, view it on GitHub<https://github.com/tableau/VizAlerts/issues/119#issuecomment-392085132 https://github.com/tableau/VizAlerts/issues/119#issuecomment-392085132>, or mute the thread<https://github.com/notifications/unsubscribe-auth/APgSSpLJi-8qvJgg5Vx7qtc9Bok0jC6Mks5t2BxAgaJpZM4OnAJT https://github.com/notifications/unsubscribe-auth/APgSSpLJi-8qvJgg5Vx7qtc9Bok0jC6Mks5t2BxAgaJpZM4OnAJT>.
If you are not the addressee, please inform us immediately that you have received this e-mail by mistake, and delete it. We thank you for your support.
— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/tableau/VizAlerts/issues/119#issuecomment-392092444, or mute the thread https://github.com/notifications/unsubscribe-auth/AAW-MXwkkqTudeblKiynlKX3ZGYvi5wVks5t2CG2gaJpZM4OnAJT.
Working with someone internally who had this need, one thought that occurred was that we could remove this restriction, but still implement a safeguard on the trigger view side in the form of another action field that denies access to non-owners. So basically we would remove the hard restriction, meaning that individuals with permissions to subscribe could do so, but authors could still implement the field to disallow them from running the VizAlert itself. That way, managing the subscription permissions wouldn't be necessary except as a way to prevent unnecessary resource consumption due to non-owners subscribing.
Just a thought--let me know if you like that idea or think it's not worth the complexity, @jdrummey .
Just a thought--let me know if you like that idea or think it's not worth the complexity, @jdrummey .
I'm liking that idea in general, and I'm thinking that in order to not break existing functionality & configurations that it would be better as "automatically opt out aka manually opt in". So whatever new field is created has to be added to the trigger view to allow subscriptions or test_alert to run, otherwise current behavior stands.
i believe it’s a great idea
From: Jonathan Drummey @.> Sent: Monday, June 20, 2022 4:51:34 PM To: tableau/VizAlerts @.> Cc: Subscribed @.***> Subject: Re: [tableau/VizAlerts] Allow non-owners to drive VizAlert execution (#119)
Just a thought--let me know if you like that idea or think it's not worth the complexity, @jdrummeyhttps://urldefense.com/v3/__https://github.com/jdrummey__;!!O7V3aRRsHkZJLA!F98ewz-BS0t-3REdB9IhTDE8nwi9BEEoPV4TrmXAv0OYjAto8ARpjKmC78L1NqUmCpyF8v4Waj0u0is2yREPat-TTgZPG2E$ .
I'm liking that idea in general, and I'm thinking that in order to not break existing functionality & configurations that it would be better as "automatically opt out aka manually opt in". So whatever new field is created has to be added to the trigger view to allow subscriptions or test_alert to run, otherwise current behavior stands.
— Reply to this email directly, view it on GitHubhttps://urldefense.com/v3/__https://github.com/tableau/VizAlerts/issues/119*issuecomment-1160545413__;Iw!!O7V3aRRsHkZJLA!F98ewz-BS0t-3REdB9IhTDE8nwi9BEEoPV4TrmXAv0OYjAto8ARpjKmC78L1NqUmCpyF8v4Waj0u0is2yREPat-TXJfoSuU$, or unsubscribehttps://urldefense.com/v3/__https://github.com/notifications/unsubscribe-auth/AH3KNKA6VXQWNNO663FDX3LVQCAPNANCNFSM4DU4AJJQ__;!!O7V3aRRsHkZJLA!F98ewz-BS0t-3REdB9IhTDE8nwi9BEEoPV4TrmXAv0OYjAto8ARpjKmC78L1NqUmCpyF8v4Waj0u0is2yREPat-TUrI2II8$. You are receiving this because you are subscribed to this thread.Message ID: @.***>
This e-mail and any attachments may be confidential or legally privileged. If you received this message in error or are not the intended recipient, you should destroy the e-mail message and any attachments or copies, and you are prohibited from retaining, distributing, disclosing or using any information contained herein. Please inform us of the erroneous delivery by return e-mail. Thank you for your cooperation. For more information on how we use your personal data please see our Privacy Noticehttps://www.oliverwyman.com/policies/privacy-notice.html.
