Docs
Project settings
Aside from the specific settings for subjects and metrics there are also general project settings. These settings can be found under the general section in the settings menu. On this page you can find what the settings are about.
General
The general settings apply for each and every person in the project. So, changing the Theme will result in a Dark or Light theme for everyone. This is what you can set:
| Field | Description |
|---|---|
| Project ID | The unique ID of your Blockbax project. |
| Name | The name of the project so you can easily find it among your list of projects. |
| Timezone | The timezone of the project. Be aware that dates are always displayed in the timezone of the project which might differ from the timezone of your computer. |
| Description (optional) | You can add a description to tell (new) project members what your project is about. |
| Theme | You can choose a Dark or Light theme, cool right? |
| Custom Mapbox style URL (optional) | A URL to a public Mapbox style for customizing the appearance of geographic maps. This is an experimental feature - if you want us to enable it for your organization please contact us. A custom public Mapbox style allows you to modify the appearance of geographic maps, such as adding advanced overlays. To use this feature, you must create a Mapbox account and design a new style in the Mapbox Style Editor. We recommend starting by copying our default dark style or light style to your account. Alternatively, you can customize one of Mapbox’s templates. Refer to this Mapbox tutorial for guidance on creating a new style, or consult the Mapbox Studio manual for more information. Eventually, you need to add the ‘Style URL’ ( mapbox://styles/...) from Mapbox in your Blockbax project settings. |
SSO settings
This setting is only available once SSO is configured at your organization’s SSO settings. For first time users, a default role can be defined to determine the level of access these users are granted.
Leave project
You can remove yourself as a member of the project. Be aware of the fact that you will lose access to the project right after you’ve hit the button ‘Leave project.’ If you want back in, you will need someone else to invite you to the project.
Change owner
This action can only be executed by the Owner of the project. As an owner of the project, you can transfer the project to someone else within the project. Especially useful when want to give someone else responsibility for the project when you are on a holiday or a well-deserved sabbatical of 3 months.
Environments
With the Environments feature, you can create and manage multiple DTAP (Development, Testing, Acceptance, Production) environments to support structured workflows. Make and test changes in one environment (e.g., Acceptance), then promote those changes to the next stage (e.g., Production). To learn more about Environments, you can navigate to the dedicated Environments documenation
Remove project
This action can only be executed by the Owner of the project. As an owner of the project, you can remove the project and all its resources. This is a dangerous action, so be very, very, very careful with this action.
Here is an example of the General settings of the Blockbax Playground project:
Roles
Roles give control on what kind of access you grant to the members of your project. From default roles to fine-grained custom roles, it’s all configurable at the project settings.
Default roles
Each project comes with default roles with fixed permissions. The permissions for these roles are the ones we see most often.
| Role | Permissions |
|---|---|
| Owner | Full access |
| Administrator | Full access but no possibility to remove a project or transfer ownership |
| Expert | Read-only, with write access to event triggers and notification settings. No access to project settings and usage |
| Observer | Read-only, with only write access to own notification settings. No access to project settings and usage |
Custom roles
Custom user roles can be used to define more fine-grained permissions for your members compared to the default roles.
Configurable permissions
| Resource | Permission | Filter(s) |
|---|---|---|
| Actions | Run | All or include certain actions |
| Dashboards | View, Edit, Manage | All or include certain dashboards |
| Inbound connectors | Use | All or include certain inbound connectors with an additional filter to select for which subjects (all, include and/or exclude) it can be used. When an inbound connector is set to automatically create subjects, only subjects that match the selection can be created. |
| Event triggers | View, Edit, Manage | All or include certain event triggers |
| Properties | View, Edit | All or include certain properties |
| Subjects | View, Edit, Manage | All, include and/or exclude certain subjects |
View, edit and manage
The platform provides three permission levels.
| Level | Permission |
|---|---|
| View | The resource is only viewable (read-only) for this role |
| Edit | The resource is viewable and editable (write access) for this role |
| Manage | The resource is viewable, editable, creatable and removable for this role |
- On a dashboard the resource access to event triggers, properties and subjects is still applied. Consequently providing just dashboard permission has no effect when the user has no permissions to the underlying resources.
- To edit a resource you need to have at least view permissions to the other resources used. For example in order to edit an event trigger you need to have at least view permissions to the subjects in scope and/or properties used.
- Editing subjects applies only to its properties where the user has edit permissions to.
Include and exclude subject permissions based on properties
The behavior of including and excluding subjects based on a property differs from selecting individual subjects.
| Filter type | Result |
|---|---|
| Include | The user gets access to the subjects that match all properties |
| Exclude | The user gets no access to the subject that matches one of the properties |
Non-configurable permissions
Some resource permissions underlying certain sections in the interface are not configurable, but are derived or only accessible via system-defined roles.
| Section | Permission | Explanation |
|---|---|---|
| Subject types | Derived | All subject types are viewable that are related to the subjects you have access to |
| Events | Derived | Events are visible for the subject(s) and event trigger(s) you have access to |
| Notifications | Derived | Notifications are constrained to the subject(s) and event trigger(s) you have access to |
| Explorer | Derived | You can always use the Explorer for the resources you have permission to |
| Usage | Owner and admin only | The default owner and admin role have permission to this section |
| Project settings | Owner and admin only | The default owner and admin role have permission to this section |
Here you see a Blockbaxer creating a custom role.
Members
Member management empowers you to keep an eye on the people and their permission in your project. At this part of the platform you can easily invite new people for your project, change roles for your project members and remove an account from the project.
Invite link
The owner of a project can create an invite link in the members section. This makes it easy to invite people to the project without knowing and typing in their email-addresses.
People that use the invite link to join the project will automatically get the observer role.
The invite link can be revoked by the owner. The invite link is invalid after revoking and can not be used anymore. The owner can always create a new one, but never activate an old one again.
Properties
Properties can be used to label subjects. This is what you need to configure when adding or editing a property:
| Attribute | Description |
|---|---|
| Name | Give the property a descriptive name so you can easily recognize and find it. |
| Data type | Choose whether the value of the property is of type text, image, number, location, map layer or area. |
| Values | Provide pre-defined values or let project members come up with values they want. |
Audit log
The audit log shows a record of project activity over the last 90 days. Blockbax keeps track of changes made to projects over time. In the audit log you browse recent activity and see who did what when. Creating subjects, modifying event triggers, updating alarms, and many more changes are all logged. There is only one exception: modifying the values of subject properties. If you do want certain property changes to be logged, you can offer an action to modify the properties instead, because action runs are logged.
Only administrators and project owners can access audit logs.
