You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Is your feature request related to a problem?
A large organization is most likely to have multiple administrators for managing cluster resources. For example, admin_a and admin_b could be responsible for managing indices index_x, index_y and associated resources such as alerts and monitors. Similarly admin_a, admin_c could be responsible for index_z.
Alerting does not have a concept of ownership, any user with the right permissions can read/delete alerting resources. #138 provided some segmentation based on backend roles.
To ease the administrative process, Dashboard tenancy provides a way to group related objects together although such support is only available for Dashboard objects such as visualizations, index patterns. For cluster owned items such as alerting, tenancy separation is not available. For example, in the above scenario, admin_a would like to group index_x and index_y related Information in one tenant and index_z in another tenant. Such tenant separation is currently available for items such as index patterns but for plugin objects like monitors.
What solution would you like?
Would like the ability to group not only Dashboard objects but Cluster/Plugin/Extension objects (specifically alerting) with tenants/workspaces
Possible approaches could be to store references to the alerting objects as part of Dashboard tenants or store tenant information as metadata in the alerting object which can then be used later as filter during display.x
What alternatives have you considered?
Considered #138 but is has few drawbacks. It does not address scenarios such as the one mentioned, requires additional backend roles to be created in some instances and end users need to be aware of backend roles that need to be mapped.
Do you have any additional context?
Add any other context or screenshots about the feature request here.
The text was updated successfully, but these errors were encountered:
Is your feature request related to a problem?
A large organization is most likely to have multiple administrators for managing cluster resources. For example,
admin_a
andadmin_b
could be responsible for managing indicesindex_x
,index_y
and associated resources such as alerts and monitors. Similarlyadmin_a
,admin_c
could be responsible forindex_z
.Alerting does not have a concept of ownership, any user with the right permissions can read/delete alerting resources. #138 provided some segmentation based on backend roles.
To ease the administrative process, Dashboard tenancy provides a way to group related objects together although such support is only available for Dashboard objects such as visualizations, index patterns. For cluster owned items such as alerting, tenancy separation is not available. For example, in the above scenario,
admin_a
would like to groupindex_x
andindex_y
related Information in one tenant andindex_z
in another tenant. Such tenant separation is currently available for items such as index patterns but for plugin objects like monitors.What solution would you like?
Would like the ability to group not only Dashboard objects but Cluster/Plugin/Extension objects (specifically alerting) with tenants/workspaces
Possible approaches could be to store references to the alerting objects as part of Dashboard tenants or store tenant information as metadata in the alerting object which can then be used later as filter during display.x
What alternatives have you considered?
Considered #138 but is has few drawbacks. It does not address scenarios such as the one mentioned, requires additional backend roles to be created in some instances and end users need to be aware of backend roles that need to be mapped.
Do you have any additional context?
Add any other context or screenshots about the feature request here.
The text was updated successfully, but these errors were encountered: