In this article we will first take a deep dive into how Collections, Suborganizations and embed users all come together to control access to your dashboards and datasets.

What are Collections?

Collections in Luzmo are a way of organizing a group of datasets and dashboards which can then be shared collectively through an embed token. There are several ways to structure collections, each with their pros and cons. From a maintenance and scalability point of view, we recommend choosing the most simple solution that fits your needs, i.e. the solution requiring the least amount of resources to manage.

What are Groups and Suborganizations?

Groups in Luzmo are used to organize users and their access to datasets as well as dashboards. When datasets and dashboards are shared with a group, you can set an appropriate access right and optionally specify some dataset filter(s). Users added or removed from the group will gain or lose access to the group’s accessible datasets and dashboards.

Suborganizations in Luzmo are like silos for your clients. By assigning a client to a Suborganization, you ensure that they can only see resources from that suborganization (e.g. users, comments, custom datasets, etc.). Each time a new Suborganization is specified in the embed authorization request, a new "suborganization group" is automatically created with the same name. An embed user will be automatically created and added to this group. Dashboards and datasets can then be shared and managed like with any other group, facilitating more granular access to specific resources.

How do collections, groups and embed Authorization Tokens work together?

When an embed token is generated for a user, access rights for at least one collection, dataset or dashboard must be specified through the access property. Suborganization can be specified via the suborganization property, if it is not specified it will default to the value of the username property.

The access rights specified for each collection, dashboard or dataset in the access properties of the embed token are joint with any other access rights (share to user or group the user belongs to).

If the user has access to a dashboard or dataset via more than one way (group or user share), the following rules are used:

  • The highest level rights (can view, can use, can edit, owner) among all given are applied
  • The filters of a specific share are respected in following order of priority: user filters > private group filters > public group filters.

The resulting filter is then merged with the embed filter(s) using "AND" relations.

For example a dataset is accessible:

  • with 'can use' rights shared with a suborganization and a filter client_id = 1
  • with 'can view' rights via a share to the user and no filter defined on that share
  • with 'can use' rights on the embed token and an embed filter active = "true"

The embed user will have 'can use' rights (the highest of the three) and filter active = "true" (from the embed filter). The filter client_id = 1 is not applied as the user share is prioritized over the suborganization (private group) share.

All filters from the dashboard (interactivity filters, dashboard filters, chart filters) are merged with the share and embed filter(s) using "AND" relations.

Getting the accessible dashboards

A complete list of dashboards and datasets available to an individual user can be found in the front end of your application by calling the getAccessibleDashboards method.

You can generate a similar list by using an user’s embed token and the following curl code:

curl https://api.luzmo.com/0.1.0/securable -H "Content-Type: application/json" -d @- << EOF
{
    "action": "get",
    "version": "0.1.0",
    "key": "{{LUZMO_EMBED_KEY}}",
    "token": "{{LUZMO_EMBED_TOKEN}}",
    "find": {
        "where": { "type": "dashboard", "derived": false },
        "attributes": ["id", "name", "modified_at"],
        "order": [["modified_at", "desc"]],
        "include": [
            { "model": "Tag", "attributes": ["tag"] },
            { "model": "User", "attributes": ["id", "name"] },
            { "model": "Group", "attributes": ["id", "name", "public"] },
            { "model": "Collection", "attributes": ["id", "name"] }
        ]
    }
}
EOF

Collections per environment

In order to track embedded dashboards from development to production, it may be advantageous to organize your collections by environment.

For example, this allows dashboards and datasets to be created and tested in a development environment collection first, then tested and evaluated in a QA environment collection before being shared with a production facing collection.

Next to controlling which dashboard shows in which environment, there is also the publishing functionality with which you can control which version of that dashboard shows in which environment. You can read all about this in this article.

If you are interested to know how you can make sure that user-generated dashboards fit seamlessly in your application, the next article will help out!

Previous
Next

Need more information?

Do you still have questions? Let us know how we can help.
Send us feedback!

Course Outline