Usersresources are available in the 2.0 API, but
Accountsare only available on the 0.5 API for now.
- In the 0.5 API, permissions and reporting permissions were set explicitly on each Role. In the 2.0 API, permissions are inherited from parent roles, and may be omitted if the parent's settings are sufficient.
- The 2.0 API has different fields and syntax for controlling reporting fields and permissions, as described below.
- The 2.0 API supports Users and Roles, but the Accounts resource is not yet available.
The diagram below shows the relationship between these resources:
Buzz supports multi-tenant usage through the establishment of Accounts that separate access for most resources. Outside of Users enabled as Multi-Account Users all actions within Buzz are restricted to the scope of the Account in which the requesting user exists.
Only Multi-Account users can create or edit Accounts or create or edit objects in Accounts other than the one in which their User was created.
Every action in Buzz is completed by a User. Users may be set as multi-account, for access across Accounts.
Every User must be assigned a Role, which determines the User’s rights to read, edit, write and delete objects as well as which reports, dashboards, and report fields they may access. A Role is defined by a series of Permissions, each of which corresponds to a resource, for example the
A set of default Roles are created are available to all Accounts for each Buzz Key. You may create a custom Role if you need different or more granular permissions than what is provided by the defaults. In these cases, the Role you create will inherit permissions from one of the defaults, using the
Sharing Roles Across Accounts
You can now create your own roles that work across Accounts! This is available to users who are enabled for multi-account.
Roles may be specific to an Account or may be used across Accounts. All default Roles work across accounts. In the 2.0 API any multi-account user can create a role to work across accounts by setting the
shared_across_accounts field to true.
Permissions are defined by the resource name (singular) and a 4-bit operator corresponding to read, create, update, and delete privileges, respectively. Permissions are set within a Role using the
If a Permission is set to 1, the User enabled can only read that type of object. If set to 3, the User can Read and Create the object (1+2). When a Permission is set to 15 then have full rights to the object (1+2+4+8). Examples:
|advertiser||7||User can read, create, and update advertisers, but not delete them|
|campaign||15||User has full access to campaigns|
|line_item||3||User can read and create line_items, but cannot edit or delete them|
|segment||0||User cannot perform any action on segments|
Roles can limit access to reports, the fields within reports, and dashboards within the UI. If these settings are left blank for a Role, the assigned Users will inherit access to those objects from the parent role. The fields in the Role object for editing these settings differs significantly between the 0.5 and 2.0 APIs.
A summary of the reporting permissions:
report_idsfield determines which reports the Role can access. A list of available reports may be retrieved from the /reporting/reports resource.
dashboard_idsfield determines which UI dashboards the Role can access. A list of available dashboards may be retrieved from the /ref/dashboards resource.
report_field_group_idsfield determines which groups of fields the Role can access. For example, you may not want certain users to have access to financial reporting data. A list of available field groups may be retrieved from the /ref/report-field-groups resource.
Updated almost 2 years ago