tableau / community-tableau-server-insights Goto Github PK

For the 02 compatibility set, we're missing Flow information in hyperlink URLs. Let's add it.

I noticed that the Project count in the data source seems to count only project where there is content in it. This provide a biased view of the content of a site and unfortunately prevent to see proliferation of empty folders.

Would it be possible to enhance the data source to include empty projects ?

See https://community.tableau.com/docs/DOC-9974#comment-42475 at Aug 15, 2019 8:17 AM.

Should also include a version of this field for the local timezone.

Hello everybody,

is there a way to join e.g. the TS Events data source with some other Google sheet?

thanks and best regards

Christoph

I recently had some folks request for the ability to see what users are in what groups more easily. Unfortunately, bringing Groups into the existing data sources would result in row duplication. Thoughts on creating a separate data source for Groups-Users? Something like this...

Cheers!

Digging into the TS Content source and it appears that the only views with fields are those that were published as sheets to server. Is it possible to pull in all fields that were published on dashboards and stories?

"Metrics" is a feature that is coming soon. This should be included in data sources-TS Content, for sure. Maybe TS Background tasks if it consumes backgrounder resources. TS Events will likely pick it up automatically, but we may need new hyperlinks for it as well as the other data sources. Point is: Needs-a-lookin'-at.

Can't have an interoperable data set with the other data sources with this dumb string in the repo URL (I mean, you can use LUID, but let's strip this out anyway so we're being consistent).

This info was missing from the earlier 01 version set for this data source which blocked #16

Now that Tableau server supports nested projects, we have a need to filter on a project name that is neither top level, nor lowest level. In this case of filtering on something in the middle of the file path, it would be helpful to have a "Full Project Path" field with values like: "\Top Level Project\Second Project\Third Project\Fourth Project" that we can do a contains filter on.

Hello,

Is there any way of collecting all user IDs with access to a specific view or project so that you calculate relative usage/reach on a project/view?

I am sorry if I have placed this request in the wrong section.

KR, Phillip

Update all compatible data sources with 2019.4--ensure they query properly, and hide uninteresting fields.

Currently TS Content holds a record for every workbook, view, published data source, and flow on Tableau Server. Currently, if you want to know what projects exist and who owns them, you can only see them for non-empty projects. Should we extend this to include a Project item type so that people can answer that question? (note, this is a great use case for the upcoming Data Modeling feature).

Both hist_workbooks and hist_datasources contain a size column, which should track the size of a given workbook or data source over time as it is changed. This could be useful for tracking ETL issues, or the growth of purely incremental extracts, or server growth overall, potentially.

Interestingly, looking at this data right now, the sizes for a single workbook look like they can vary wildly over time. I'm not entirely sure why that would be the case, so it'd be wise to dive into this data a bit more before just throwing that field into the data source.

Currently, data roles appear as Datasources in TS Content. We'll have to introduce these as a new Type, and ensure they're being categorized properly.

Flows can contain extracts, which can be important to know. We're nulling this field out for Flows in TS Content right now, and we should quit doing that.

We created some new features for TS Background Tasks in the 02 version set that were never added to the old 01 version set. One was adding the Project Owner email and user name. Let's catch the old version up so that customers on older versions (of whom there are many) can enjoy these features as well.

This data source lacks a starter dashboard that demonstrates basic use cases. We should consider adding one.

Due to the way the data is structured for Data Alerts in the background_jobs table, we never properly integrated that job type into the TS Background Tasks data source. As such, it's very difficult to determine what alerts are running against what content. Previously, I had done some experimenting trying to parse the ID out of the [args] column, but that proved problematic for performance (but, being honest, we're already struggling with that anyway).

We should revisit this and try again to integrate alerts into the data source, and if performance is a problem, I think we should change the recommendation to extract this data source, incrementing on completed_at.

Sir,

Is there any way we can identify LUID's or some other way to identify those extract refresh schedules which are in suspended state so that they can be removed.Instead of deleting the schedule ( which might be used by other users as well) , I would remove the individual extract refresh task set on that particular workbook.

Reason behind doing this is: To reduce the error failure rate in an extract heavy environment.

(sorry for all the posts 😛 )
[TS Background Tasks Query].[Finish Code] actually has 3 values:
0 = Success
1 = Failed
3 = Cancelled

I believe the only calculated fields that depend on this are:
Job Result
Job Status

Please let me know how I can help with this.

https://community.tableau.com/message/1015761

There are several ways to determine which requests are particular to AskData, and we're not capturing them all in the current calc.

(also we did not apply the AskData calc in ts_web_requests to the 02 compatibility set at all, so it needs to be added)

ELSEIF USERNAME() = [Owner Role] // If the user is the owner of the content for this row, let them see it

should be

ELSEIF USERNAME() = [Owner Sysname] // If the user is the owner of the content for this row, let them see it

Suggestion. The display_name field in site_roles table does the work of the "Site Role" calculated field in the data sources. "Site Role" could probably be replaced. This is 2019.3 and 2020.1. Not sure about earlier versions.

Currently TS Content holds a record for every workbook, view, published data source, and flow on Tableau Server. Currently, if you want to know what customized views exist, you can't see them. Should we extend this to include a Customized View item type so that people can answer that question? (note, this is a great use case for the upcoming Data Modeling feature).

We're inconsistent with our Item LUID information across data sources (example, TS Web Requests lacks it). Any attempt to join / blend data sources is made much more difficult without this field.

In 2019.4, a field was introduced into the backgrounder_jobs table called job_creator. This indicates who created the job, which has been a frequent request for admins wanting to know who initiated an "run now" extract refresh, and the like. This also becomes more important with the introduction of the Create Extracts in Browser feature introduced in 2019.4 as well. Note, though, that this only works for new tasks, and will not back-populate already existing tasks.

Edit: Additionally, there's a new flag in the backrounder_jobs table called ‘run_now’, which can be used to determine whether jobs were scheduled, or run on-demand.

Given that 2019.4 is almost done, and still on the 02 version set, I think we should target the 03 version set (2020.1+).

This field indicates whether permissions are locked to the project level, which is useful general information when using TS Content, even though it does not contain any other permissions information. An example would be deciding whether it'd be fine to move a project underneath another one--if one is locked, and the other isn't, permissions on the second would be overwritten if it were moved under the first, so that'd be a situation one might want to resolve before moving it.

We're inconsistent with our Site information across data sources (example, TS Events vs TS Web Requests). Any attempt to join these two data sources (which I do not recommend) cannot properly be done without matching the Site information. This is best done via LUID, but adding ID could not hurt. We should add fields to each data source so that they are consistent.

How could I consolidate all TS datasources into one single workbook?

Because I will build a few customized admin dashboards based on TS content, TS event and TS web request etc. I want to embed the data model in the workbook itself, rather than to connect to separately published data sources. It seems very troublesome to replicate each TS data source. Is there any easier way to combine them into one single workbook?

When trying to connect to the TS data sources previously built in this community I'm getting an escape error. I've made sure permissions were set up correctly and that the data sources were working before. Now I'm getting this error message:
""
An error occurred while communicating with the data source.

The connection to the data source might have been lost.
ERROR: invalid regular expression: invalid escape \ sequence;
Error while executing the query
prepare.xml
DataServiceFailure
No details available.

In the example below I have two data published sources, one on one site, and one on another.
There's two workbooks on each site and both contain an embedded data source referencing their site's respective published data source.
However you can see below [TS Data Connections] reports two underlying data sources for each workbook - one is the correct one, but one is the corresponding data source from the other site.

Is this a bug? Can it be rectified?
I am trying to count the number of workbooks connected to each data source, but I'm getting the wrong information.
If I was to count the workbooks connecting to data source 3774, I'd get 4 - two on the Default site and two on the Development site. Now this has to be wrong, of course, because we know we can't connect a workbook on one site to a published data source on another.

Thanks

Stub to investigate. Seems like there may be a bad join here that doesn't properly consider sites.

Looks like this isn't capturing all the exports. In 2020.2 at least, exporting from View Data to CSV isn't showing up.

During the last release, I tried hard to integrate Prep flows into the TS Data Connections data source. After a long struggle, I couldn't find a logical way to integrate it in. At this point, I can't recall why it was so hard to do. But the basic idea is that Prep flows have both inputs and output connections, and either can be a published data source on Tableau Server.

Wasn't sure if I should post this here or in the developer's forum. For our deployment I'm considering using the user filters on these data sources, but I'm wondering if they are really necessary.
Things I am not worried about:

• who does what and when
• What reports exist, even if they don't have access
• when others' extracts are run

It would sure save me the headache of "it's not my data source, but I need to know how the extract is running" type questions.

I'm wondering if I'm missing anything that I should be concerned about. (yeah, every company is different...just spitballin' here)

Cheers,
Chadd

We created some new features for data sources in later 02 version sets that were never added to the old 01 version set. Add new permissions strings to it and edit the User Filter calc appropriately.

We get a lot of requests for a data source to help folks author dashboards that expose permissions. It'd be great to collect some use cases in the comments here so we can build the best version possible.

It would be great to take advantage of Relationships in 2020.2 to reduce duplication in the data.

Looking further into this, the security model will break due to the lack of joining on calculations.https://kb.tableau.com/articles/issue/Unable-to-Define-Relationships-Based-on-Calculated-Fields-or-Geographic-Fields

The new Data Catalog feature includes several new tables which can be useful for understanding underlying connections in Tableau Server. A non-exhaustive list:

column_assets
table_assets
database_assets
data_quality_indicators

There are also hist_* tables for each of these, along with *_events tables. These tables are all generated in the process of Data Catalog discovering and tracking what assets it has processed into the GraphQL database for Catalog.

On the database_assets table, the source_type and source_id can be used to join to the workbooks or datasources table. It's not clear that these can be linked to a data_connections record, though, which is what would be needed to determine which connection used the assets in question, though. There also seems to be no link between columns as found in databases in general, and how they're used in a given workbook or data source. Nor is there any link yet between a view and it's data connection(s).

On the whole, I tend to think we're probably better off just incorporating some basic fields from data_quality_indicators into this, and offloading the heavy lifting for what-uses-what logic to Data Catalog.

There's already the ability to create wiki pages, we just need to actually create them:

https://github.com/tableau/community-tableau-server-insights/wiki

The field extract_encryption_state in workbooks, datasources, and flows (?) denotes the status for whether the extract backing the content is encrypted or not. We should include this in TS Content.

Have had several customers ask how they could deploy these data sources for all Site Admins...one who had 290 sites on their Server instance. Let's write some documentation about how to do this effectively.

We should LOWER() all LUID fields in all data sources, because the REST API returns them in all lowercase, and they're stored as uppercase in the PostgreSQL repository. Case sensitivity will prevent a match when data sets from both sources are joined. The whole point of including those fields was to make these data sources easy to use with the REST API, so we can take one pain point out of that process by doing this.

Adding next update date of extract refresh from schedules table will help in certain scenarios where we want to compare between last few runs and when it's scheduled for next run.

More than a bug I was wondering if this awesome source is getting an update to support newer versions of Tableau Server up until 2021.1.

Thanks in advance for taking the time to respond to this.

Add a field called "Version" to all data sources to indicate version, once published. Considered using a parameter instead, but as this often is overridden by workbooks, and conflicts when multiple data sources are used in a single workbook, I figured a simple calc would be better.

At some point, the obj_type field in the tasks table stopped being populated (need to research what version this phenomena appeared in--not clear if this is a bug, or an intentional change). This breaks the logic used to populate Item Owner information for the Subscriptions task type.

A workaround would be to pass the workbook_id value for workbook-based subscriptions and the owner_id for any subscription in the "sub" subquery, then modify the join to workbooks so it uses that OR the original logic, and that's probably what we'll have to do.

The "vud" action stands for "view underlying data", but seems to correspond with an actual download of the text file for the underlying data, not simply viewing all columns in the web tab "Full Data".

Instead, the raw Controller field is where the granular details are tracked, which we sanitize as Interaction. The values to look for are:

tabdoc/get-summary-data
tabdoc/get-underlying-data

So it seems like we should at least clarify this in a comment on Action, since we'd indicated "vud" was viewing underlying data, which you can access a sample of from the web interface, not necessary just full exports of it.

Taking it up a notch, I suppose we could encode those interactions as "viewData" and "vud" types to help users more, though it's more to maintain / validate.

Howdy! Thanks so much for putting this on gitlab! On my version of the TS Users, I had to modify the Site Role calc to accurately identify the Viewer role:

IF [Admin Level_orig] = 10
    THEN 'Server Administrator'
ELSEIF [Site Role_orig] = 'Author'
    THEN 'Creator'
ELSEIF [Site Role_orig] = 'Publisher'
    THEN 'Explorer (can publish)'
ELSEIF [Site Role_orig] = 'Interactor'
    THEN 'Explorer'
ELSEIF [Site Role_orig] = 'BasicUser'
    THEN 'Viewer'
ELSEIF [Site Role_orig] = 'SiteAdministratorAuthor'
    THEN 'Site Administrator Creator'
ELSEIF [Site Role_orig] = 'SiteAdministrator'
    THEN 'Site Administrator Explorer'
ELSE [Site Role_orig]
END

There is no [Site Role_orig] of Viewer.
Here is the original

IF [Admin Level_orig] = 10
    THEN 'Server Administrator'
ELSEIF [Site Role_orig] = 'Author'
    THEN 'Creator'
ELSEIF [Site Role_orig] = 'Publisher'
    THEN 'Explorer (can publish)'
ELSEIF [Site Role_orig] = 'Interactor'
    THEN 'Explorer'
ELSEIF [Site Role_orig] = 'Viewer'
    THEN 'Viewer'
ELSEIF [Site Role_orig] = 'SiteAdministratorAuthor'
    THEN 'Site Administrator Creator'
ELSEIF [Site Role_orig] = 'SiteAdministrator'
    THEN 'Site Administrator Explorer'
ELSE [Site Role_orig]
END

I'd submit the fix, myself, but I am not good at git 😆