Tableau Server 10 REST API Irritations

Version 1

    I'm starting a list of real-life Tableau Server REST API irritations, based on problems and limitations i have seen in my day to day work. My work is mostly with account management, so this list is heavily skewed in that direction. My goal is to have this in hand in case one day i have a chance to present it to someone in Tableau.

     

    Here's the current list. Please feel free to contribute.

     

    How many unique identifiers do we need?

    Tableau user accounts can be uniquely identified by the login id (aka “name”) and the internal numeric id used in the Postgres database. Tableau’s REST API introduced yet another unique identifier, the “REST ID” - a long string of random digits and dashes. This is the first clue that the REST API was “ducktaped in” rather than an integral part of the application. Moreover, there are no easy ways to convert from most of the REST IDs to the kind of id that a human would know about.

     

    Until recently, the most painful problem was a lack of conversion from the login id to REST ID. The only way to accomplish that was to scan through every user account in the system (potentially thousands of them) until you found the one you’re looking for. Recently this has been alleviated by the inclusion of a filter parameter for the REST call to list user IDs. No such fix was done to groups and projects.

    Lack of JSON support

    These days, JSON support is practically a given when dealing with any REST interface. Not so with Tableau; XML is still the only format supported.

    Ambiguous or wrong documentation

    The documentation for filter expressions states: “Field names, operator names and values are case sensitive.” Not so – at least searching for user “name” (login id) is not case sensitive. Ideally, there should be case sensitive and case insensitive operators for string comparisons.

    No good way to find a group by name

    Currently you have to scan through all groups in a site (potentially hundreds) until you find the one you’re looking for.

    No good way to find a project by name

    Currently you have to scan through all projects in a site (potentially hundreds) until you find the one you’re looking for.

    No good way to find groups that user is member of

    The only way to list all groups that an user is member of (a trivial thing in SQL) is:

    1. List all groups in a site (potentially hundreds of them);
    2. For each of these groups, list all the users who are members (potentially hundreds or thousands of them);
    3. Scan the member list looking for the account you’re interested in.

    No way to find user’s email address

    The “Query User On Site” call returns

    • REST ID
    • Login id (“name”)
    • Full name
    • Site role
    • Last login
    • External user id
    • Authentication type

    But not the user’s email address. I imagine it was an oversight. So currently it’s possible to set the email addres, but not retrieve it.

    There is no atomic way to create a new user account

    Account creation is divided in two calls:

    1. Add User To Site
    2. Update User

    If the first one succeeds and the second fails, we end up with a partially initialized user account.

    Certain user attributes can only be set by a server administrator

    Site administrator can create an account, but cannot set the user’s full name and email address. This forces us to have server admin accounts for user creation, when a site admin account should have been enough. This violates the least access security principle.