110 lines
3.5 KiB
GraphQL
110 lines
3.5 KiB
GraphQL
########################################################
|
|
# Request/response
|
|
########################################################
|
|
|
|
type GenericResponse {
|
|
result: [JSONObject!]
|
|
error: ApiError
|
|
}
|
|
|
|
type ApiError implements Error {
|
|
code: Int
|
|
message: String
|
|
data: JSONObject
|
|
path: String
|
|
args: JSONObject
|
|
}
|
|
|
|
interface Error {
|
|
code: Int
|
|
message: String
|
|
data: JSONObject
|
|
}
|
|
|
|
|
|
########################################################
|
|
# User permissions
|
|
########################################################
|
|
|
|
input PermissionRequest {
|
|
permission: Permission!,
|
|
"""
|
|
objectName maps to name / path suffix of the template group representing the permission in Zabbix:
|
|
Permissions/{objectName}
|
|
"""
|
|
objectName: String!
|
|
}
|
|
|
|
"""
|
|
READ, READ_WRITE or DENY:
|
|
describes the rights related to an objectName
|
|
There is no EXECUTE or anything else in Zabbix,
|
|
i.e. objectName - Tree has to be designed accordingly in order to represent the perform actions.
|
|
|
|
E.g.
|
|
|
|
Let's assume a button called "button1", used in application "app1", having a label which shows "do something". Instead of model the action "do something" the idea is
|
|
to model the effect of this action - do something will result in a status change. Let's further assume that the button will only
|
|
be displayed if the user is allowed to see the current status.
|
|
|
|
Permissions/app1/button1/status
|
|
|
|
The following PermissionRequests would be used by the frontend:
|
|
|
|
1. Should the button (and its status) be displayed at all?
|
|
button1.displayed = hasPermissions(
|
|
{
|
|
objectName: "app1/button1/status"
|
|
permission: READ
|
|
})
|
|
2. Should the user be able to press the button (enabled)?
|
|
button1.displayed = hasPermissions(
|
|
{
|
|
objectName: "app1/button1/status"
|
|
permission: READ_WRITE
|
|
})
|
|
|
|
|
|
Usage Example for this pattern: Activation/Deactivation of a control program - the button
|
|
shows the possible action. If the program is active it shows "Deactivate". If the program is inactive it shows "Activate".
|
|
From this label the user learns something about the current state - therefore the status - read - permission is needed in order
|
|
to display the button at all. The status write permission is needed in order to enable the button (i.e. allow the user to press it).
|
|
in order to model the permissions to press / see a button "button1" belonging to application "app1"
|
|
the following template group could be modelled in Zabbix
|
|
"""
|
|
enum Permission {
|
|
"""
|
|
DENY superseeds anything else - i.e. if in Zabbix there is a DENY and READ at the same time the result will be DENY
|
|
"""
|
|
DENY
|
|
"""
|
|
READ superseeds READ_WRITE - i.e. if in Zabbix there is a READ_WRITE and READ at the same time the resulting permission
|
|
level will be READ
|
|
"""
|
|
READ
|
|
"""
|
|
READ_WRITE implies the READ permission. Do not set both READ and READ_WRITE at the same time if you want to achieve
|
|
READ + WRITE permission, because in this case READ will superseed the READ_WRITE and the resulting permission level will be READ
|
|
"""
|
|
READ_WRITE
|
|
}
|
|
|
|
type UserPermission {
|
|
permission: Permission!,
|
|
"""
|
|
objectName maps to name / path suffix of the template group representing the permission in Zabbix:
|
|
Permissions/{objectName}
|
|
"""
|
|
objectName: String!
|
|
}
|
|
|
|
|
|
############################################################################
|
|
# General purpose types + enums
|
|
############################################################################
|
|
enum SortOrder {
|
|
"Deliver values in ascending order"
|
|
asc
|
|
"Deliver values in descending order"
|
|
desc
|
|
}
|