7 Replies Latest reply on Sep 2, 2015 9:48 AM by Toby Erkson

    1.0.4 Feedback: A Running List

    Matt Coles

      This is a list of all bugs, issues, feature change requests, or documentation deficiencies reported in v1.0.4 of VizAlerts, for tracking purposes. I'll keep this up to date with newly reported issues, and add notes should they be fixed in a newer version. Alongside each is who found / suggested each issue / feature request:


      Items struck through have been fixed in the latest version. All other items will carry over.


      Bugs:

      1. HTTP errors during data exports are not reported in failure emails. Also need to translate HTTP status codes to intelligible, actionable information (e.g., 403 = subscriber doesn't have permission, 406 = viz render failed; click this link to see error) (matt c)
      2. (Related to 1) Failure emails are in HTML format, obscuring any content indadvertantly enclosed by angle brackets. (matt c)
      3. Customizing the viz.data.retrieval_tries setting in vizalerts.yaml file does not work; subsequent retries will fail because a new trusted ticket must be generated for each retry (matt c)
      4. Site support breaks if the site's Name differs from the ID (toby e)
      5. Subscribing to a view on a Site having a duplicate version on a separate Site causes logs and state file to rapidly increase in size. (toby e)

       
      Functionality Changes:
       

      1. Add human-friendly view, subscriber, workbook, etc names to state file (toby e)
      2. Support plaintext email in Advanced Alerts (toby e)
      3. In a single email for an Advanced Alert fails, do not stop processing remaining email (toby e)
      4. Provide an intuitive way for end users to trigger a given VizAlerts manually for testing (toby e)
      5. Support additional formats for embedded content in Advanced Alerts (csv, pdf, png, etc) (toby e)
      6. Add footer link for web editing alert viz, so long as user has permissions (matt c)
      7. Add support for subscribing to an entire Workbook (david l)
      8. Improve processing failure emails: Add server, site, project, workbook, view, view id, owner, subscriber... (toby e)


      Documentation Changes: 

      1. Add an "advanced setup" section to the install guide. (toby e)
      2. Expand the images in the documentation so they are more readable (toby e)
      3. Fix title in User Guide (toby e)
        • 1. Re: 1.0.4 Feedback: A Running List
          Matt Coles

          toby.erkson.0 : I spent awhile thinking about how to do a one-time alert test that would allow non-admins to test their own alerts and can't think of a good way to do it, since Tableau Server does not provide a programmatic way to delete a Subscription. If it did, the Admin could designate a specific Schedule as the "one time only" schedule, then VizAlerts could immediately remove the subscription from it once it had executed the alert one time. Since I can't do that, I'd be stuck doing something with the user manually unsubscribing, or adding/removing tags, or something like that, and all of those options just seem confusing and probably less helpful than having people just temporarily subscribing to an "every 15 minutes" schedule, letting it run, then remembering to unsubscribe themselves from it.

           

          I definitely think it's a good feature to have--If you have any ideas yourself on what could be done to implement it currently, I'm all ears!

          • 2. Re: 1.0.4 Feedback: A Running List
            Toby Erkson

            Matt Coles wrote:

             

            toby.erkson.0 : I spent awhile thinking about how to do a one-time alert test that would allow non-admins to test their own alerts and can't think of a good way to do it, since Tableau Server does not provide a programmatic way to delete a Subscription...

            Walk on over to the development team and tell 'em I'll buy all directly involved a shot of The Macallen or Balvini scotch (12-15 years) at the conference if they get that functionality into the 9.1 release

            • 3. Re: 1.0.4 Feedback: A Running List
              Matt Coles

              Would that they could be bought for that much!

              • 4. Re: 1.0.4 Feedback: A Running List
                Toby Erkson

                I would like the option in the viz to show -- or not show -- the "from view sheeName" text & link.

                This is the default:

                But for some VizAlerts I would like to only show this:

                The reason being I have administration reports that only I need to see, not the end user, but I want them to get the email notification.

                • 5. Re: 1.0.4 Feedback: A Running List
                  Matt Coles

                  Hmm, interesting. The main reason I have that footer in there is not just for the owner of the alert, but in case anyone spams everyone inadvertently, they know who and where it came from.

                   

                  Would you want any author of an Advanced Alert to be able to customize the footer for their email? Even erase it altogether if they wanted? What I'm thinking is, the standard footer would remain in place for Simple Alerts and any Advanced Alert that didn't use the Email Footer ~ field in their data. Once the Email Footer ~ field is pulled into the data, the standard system footer would be overwritten with whatever the user specified.

                   

                  Do you think that'd work for you?

                  • 6. Re: 1.0.4 Feedback: A Running List
                    Toby Erkson

                    Matt Coles wrote:

                     

                    Hmm, interesting. The main reason I have that footer in there is not just for the owner of the alert, but in case anyone spams everyone inadvertently, they know who and where it came from.

                    Agreed, the footer is fine, I just would like the ability to exclude the sheet.

                     

                    1.  Would you want any author of an Advanced Alert to be able to customize the footer for their email? Even erase it altogether if they wanted?

                    2.  What I'm thinking is, the standard footer would remain in place for Simple Alerts and any Advanced Alert that didn't use the Email Footer ~ field in their data. Once the Email Footer ~ field is pulled into the data, the standard system footer would be overwritten with whatever the user specified.

                     

                    Do you think that'd work for you?

                    1.  Sounds good.  Customizable as well as erasing it.  However, to your original comment, I think a footer with the author's email is a good idea so the recipient can contact them for whatever reason.  So if you don't want to have it erasable then I'm fine with that.  To what I mentioned, having the option to simply not have a link to the report would be an option I would utilize for administration reporting.

                    2.  Simple Alerts - Agreed.  Advanced Alert - That's a great idea!  I could roll wit dat

                    • 7. Re: 1.0.4 Feedback: A Running List
                      Toby Erkson

                      Change the title in the User Guide document.  Currently it reads that it is an installation guide: