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.
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:
|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?|
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.
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.
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:
Member management empowers you to keep an eye on the people who have access to your project. There is one page from where you can easily invite new people for your project, change roles for your project members and remove an account from the project.
The roles defined
|Administrator||Full access but no possibility to remove a project or transfer ownership.|
|Expert||Read-only, with only write access to event triggers and own 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.|
For the observer role, it is possible to specify the subjects a member has access to. Be aware that an observer will see all the metrics and triggers, so also the ones that are not active for the subject(s) he is allowed to see. Notifications will only be send for an event that belongs to a subject that you have access to.
Here you see a Blockbaxer adding a observer with specific subject permissions to a project :
Properties can be used to label subjects. This is what you need to configure when adding or editing a property:
|Name||Give the property a descriptive name so you can easily recognize and find it.|
|Type||Choose whether the value of the property is text or number(s).|
|Values||Provide pre-defined values or let project members come up with values they want.|
Access tokens are needed to authenticate with our APIs. You can easily create one by giving the token a descriptive name to easily recognize and find it. Next, you can set the permission to constrain the person or system on what it can do with your data. Once created, you have to copy the token information and use it straight away, because you won’t be able to see it again.
|Full access||Full access, the token can be used to read and write all data|
|Measurement writer||Partly access, the token can be used to write new measurements.|
|Read only||Read-only, the token can be used to read the data.|
Like the members permissions, it is possible to specify the subjects where the Measurement writer and Read-only token have access to.
Here you see a Blockbaxer creating an access token with specific subject permissions.
Webhooks are developed to send events to other systems in real-time. You can see it as a reversed API: provide your endpoint and the platform makes sure you get the events you are interested in once they occur. The following information needs to be present to make use of the webhook.
|State||Active or Inactive|
|Name||A descriptive name to recognize and find your webhook|
|Endpoint||The URL where the platform needs to POST the events to.|
|Authorization header||Provide an optional header to authorize the webhook for your external system|
Here you can select the event levels for which the webhook should be called. For example, you might only want to see Problem and Warning events being send to your external system.
Here you have some filter options to only have the webhook called for certain event triggers.
Here you have some filter options to only have the webhook called for certain subjects.
The structure of the JSON message that is sent to the endpoint can be found in the integrations section of the docs.