Admin Users must be able to access all monitors

[skkosuri-amzn]

Is your feature request related to a problem? Please describe.
Admin Users must be able to access all monitors.

Describe the solution you'd like
Admin Users must be able to access all monitors. <TODO: add more details>

Describe alternatives you've considered
A clear and concise description of any alternative solutions or features you've considered.

[dbbaughe]

Should it just be "Admin" users that we support this for? Or should it be at the permission level, i.e. anyone with a superset of permissions that overlap a job should be able to view it? And what happens when someone w/ more permissions or a single unique role/permission updates the job and now other people can't view it? I think that can be solved w/ allowing the user to choose what roles/permissions should be stored on the job?

[skkosuri-amzn]

"admin" users here refer to users with all_access role and OR admin_dn users configured in OpenSearch.yml .

Along with this change we plan to implement #128, which will remove role/permission updates to the job.

Also roles selection is also planned during the monitor creation, and plan to support only in API first.
#138

[dbbaughe]

Will you do 138 and 128 at the same time? Otherwise if you do 128 first it might cause issues, i.e. someone creates a monitor w/ all the triggers and then realize they are missing a permission -> get the required permission and try to update the monitor -> and now they can't -> they have to recreate the entire monitor instead.

[skkosuri-amzn]

Yes targeting all three #139 , #138, #128 for 1.2.0

[ryn9]

@skkosuri-amzn

Do you mean "OR" ...

"admin" users here refer to users with all_access role and admin_dn users configured in OpenSearch.yml .

IE - "admin" users here refer to users with all_access role OR admin_dn users configured in OpenSearch.yml .
This is otherwise limited in environments where the opensearch.yml is able to be edited.

Would you consider a new role (IE - alerting_admin_access) that has this access?

[ryn9]

@skkosuri-amzn

Yes targeting all three #139 , #138, #128 for 1.2.0

I don't see any references to these on the roadmap for 1.2.0.
Can the roadmap be updated to the reflect these upcoming changes?

[skkosuri-amzn]

@skkosuri-amzn

Yes targeting all three #139 , #138, #128 for 1.2.0

I don't see any references to these on the roadmap for 1.2.0. Can the roadmap be updated to the reflect these upcoming changes?

Thanks for the callout. Will add to the roadmap by early next week.

[ryn9]

@skkosuri-amzn

Would you be able to answer ...

Do you mean "OR" ...

"admin" users here refer to users with all_access role and admin_dn users configured in OpenSearch.yml .

IE - "admin" users here refer to users with all_access role OR admin_dn users configured in OpenSearch.yml .
This is otherwise limited in environments where the opensearch.yml is able to be edited.

Would you consider a new role (IE - alerting_admin_access) that has this access?

[skkosuri-amzn]

@skkosuri-amzn

Do you mean "OR" ...

"admin" users here refer to users with all_access role and admin_dn users configured in OpenSearch.yml .

IE - "admin" users here refer to users with all_access role OR admin_dn users configured in OpenSearch.yml . This is otherwise limited in environments where the opensearch.yml is able to be edited.

Would you consider a new role (IE - alerting_admin_access) that has this access?

@ryn9 yes, OR. Thanks for catching it.

[ryn9]

@skkosuri-amzn

Would you consider a new role (IE - alerting_admin_access) that also has this access?

.

Will add to the roadmap by early next week.

Have all the additions to the roadmap been completed?

[skkosuri-amzn]

Added #202 to the roadmap.

[qreshi]

Closing this issue as the change has been merged.