automate org profiles

[lmeyerov]

A user asks if there is a way we can automate away the auth config parts of setting up the component, as each time, they need to fill it in. Think servername, and with coming SSO, the endpoints/orgname around that. (Related: we might add some branding features here later too.)

Some ideas:

• build time:
  • as part of release flow, we can do branded builds based on a list of org + profile
  • we can make a download service that makes it on-the-fly
• runtime:
  • make the component check for a .profile file somehow
  • maybe something in pbi / capabilities.json ?

[dm-p]

I'm interpreting the user story as:

"as a report creator, I want the visual to pre-populate the credentials for my organisation, so that I don't have to look these up or manually provide them each time I create a new visual."

Please let me know if I'm getting this wrong, but I'll work on this assumption.

If so, then this can be done via report themes, where it is possible to create an entry for the custom visual (by GUID). This is how commercial vendors manage their client processes (e.g. auto-population of license key in a hidden property).

The MS docs don't cover this specific scenario, but I have a guide for one of my visuals which demonstrates how you would set this up for that particular GUID. This may give you enough of an idea, but I'm happy to dedicate some time to setting this up - I'll just need confirmation as to which properties you want setting up as part of the work.

Regarding your proposed approaches, these could be managed as follows:

• Local file: due to the iframe sandbox, loading local files is not permitted due to CORS restrictions against the null origin, but you can use the JS file API to prompt an upload dialog and process a file this way. This would still introduce some friction for the user, however, as they will need to browse to the file and select it.

• During build: you set the defaults for these properties in the [appropriate settings class].ts file, or have them look up values from a suitable file that can be imprted via TS and packaged as part of the build process. I usually use a JSON file local to the source with complier.resolveJsonModule = true in tsconfig.json.

[lmeyerov]

I think the scenario is more like, the user is making different reports, and often putting in the graphistry visual component, and wants to minimize effort copy-pasting in information like "graphistry-server.company.com", "https//sso-endpoint.company.com" .

It sounds like you're saying we can do something like:

Graphistry:

• generate a per-org Report Theme file, with field entries for server, sso endpoint, etc
• create our generic visual component as before
  • ... with a hook for the Theme to use

Author:

• creates a new report
• imports graphistry visual component
  • might be skipped if PowerBI Admin preinstalls component everywhere?
• imports per-org graphistry report theme
  • can this be skipped via a PowerBI Admin?
• activates theme somehow

[dm-p]

The theme approach is probably the most streamlined, but there is still some friction in the form of how the theme file is applied to the report as it needs to be imported. Orgs will often have a theme file that they maintain along with a bunch of other things they want consistently applied, and then make a template (.pbit) file available with this already loaded, so it may be a case of providing them with the config to add to their own theme's JSON, or providing a theme file for users to apply t their reports in the absence of one.

When the visual is created on the canvas, it will check the theme file for any property overrides and apply them as defaults over the ones that are packaged-in.

If you're looking for something more centrally-managed (other than template files, which are the go-to for org-wide deployment) then building the visual with org-specific properties may be the way to go. This could then be managed via admins in the organizational visuals area (which would make the visual visible to all members of the org in a local 'store' without having to import it manually).

Working on the assumption that you're planning to publish to AppSource and certify (which IIRC we did discuss as being on the roadmap), then a visual should be packaged as generically as possible, as any user can download it. They may not have the credentials to access, but if they were packaged in then it would be a huge no-no, I'm sure.

Once a visual is packaged to AppSource, it's GUID goes into the list of known ones that Power BI Desktop/Service needs to check for at initialisation time and see if updates are needed (and deploy them if so), and this is how updates are managed for end-users. Organizational visuals work in a similar manner, but closer to the tenant (so can 'override' the version for an org if admins wish to support certain versions that have been superseded by AppSource).

If AppSource is your strategy, I'd advise the theme route and the degree of friction around having to apply the theme file to reports. If some users are okay with being provided their own version that has packaged property values (and is not tied to AppSource), then I'd suggest applying a custom GUID to pbiviz.json also, so that Power BI doesn't replace it with the published version (which is a common scenario when people fork published visuals, make changes and then try to apply them to their reports).