Uploaded image for project: 'Opsgenie'
  1. Opsgenie
  2. OPSGENIE-268

Ability to map Opsgenie user roles with Atlassian cloud user management/ Atlassian access identity

    • Icon: Suggestion Suggestion
    • Resolution: Unresolved
    • Settings - Roles
    • None
    • Our product teams collect and evaluate feedback from a number of different sources. To learn more about how we use customer feedback in the planning process, check out our new feature policy.

      It would be helpful if we can map the Opsgenie user roles direct from the Atlassian user management/Atlassian access. This way a site admin can change the role of an Opsgenie user directly from the Atlassian site's end

            [OPSGENIE-268] Ability to map Opsgenie user roles with Atlassian cloud user management/ Atlassian access identity

            Stian Bentsen Sveen added a comment - - edited

            @Dakotah Sorry for the late reply here, but basically what @Majken said.

             

            We'd like to be able to f.ex have 3 different OpsGenie groups in our IdP and then the user automatically gets access and that user role in OpsGenie based on their membership.

            So f.ex OpsGenie-Users, OpsGenie-Developer, OpsGenie-Admins and whichever group they are in would automatically create the user in OpsGenie (if it didnt already exist) and set their role based on that group membership.

            If the user is removed from any of the groups, deprovision that user (remove them from OpsGenie so they dont use a license).

            Now I add them to the group which gives them product access, then I manually have to add them to OpsGenie and give them a role.

            This is how we typically delegate access to both Jira and Confluence but on projects and spaces instead, so f.ex a user thats a member of "JIRA-Project-XYZ" would get user access in that project, but if a project has non Jira admins administrating the project, we also have a "JIRA-Project-XYZ-Admins" that would give admin access to that project instead.

             

            Br,

            Stian

            Stian Bentsen Sveen added a comment - - edited @Dakotah Sorry for the late reply here, but basically what @Majken said.   We'd like to be able to f.ex have 3 different OpsGenie groups in our IdP and then the user automatically gets access and that user role in OpsGenie based on their membership. So f.ex OpsGenie-Users, OpsGenie-Developer, OpsGenie-Admins and whichever group they are in would automatically create the user in OpsGenie (if it didnt already exist) and set their role based on that group membership. If the user is removed from any of the groups, deprovision that user (remove them from OpsGenie so they dont use a license). Now I add them to the group which gives them product access, then I manually have to add them to OpsGenie and give them a role. This is how we typically delegate access to both Jira and Confluence but on projects and spaces instead, so f.ex a user thats a member of "JIRA-Project-XYZ" would get user access in that project, but if a project has non Jira admins administrating the project, we also have a "JIRA-Project-XYZ-Admins" that would give admin access to that project instead.   Br, Stian

            Wanted to add that it occurred to me that maybe we could use the API in the mean time, but since we have Opsgenie connected to Atlassian Access, we can't use the API to update a user - even though we want to change something Access can't.

            Majken Longlade added a comment - Wanted to add that it occurred to me that maybe we could use the API in the mean time, but since we have Opsgenie connected to Atlassian Access, we can't use the API to update a user - even though we want to change something Access can't .

            Do you have any news about this request, it would be very helpful to have it! I've been waiting for her for a while.

            Emiliano Fernando Cicarelli added a comment - Do you have any news about this request, it would be very helpful to have it! I've been waiting for her for a while.

            @majken, 

             

            Let me look into some solutions for this. 

            Dakotah Jackson added a comment - @majken,    Let me look into some solutions for this. 

            d69da5e46bac - in Confluence itself you can assign permissions to groups, so you can have say an "all-space-admins" group and set your default space permissions to grant that group space admin. Opsgenie doesn't see or use groups from users like Confluence does. So any groups that you grant Opsgenie access to, the users are all just assigned the default "user" role. You can't even grant the "admin" role.

            If you're seeing something different I'd be very interested. Though I'm also using Opsgenie stand alone, not part of JSM, in case that makes a difference.

            Majken Longlade added a comment - d69da5e46bac - in Confluence itself you can assign permissions to groups, so you can have say an "all-space-admins" group and set your default space permissions to grant that group space admin. Opsgenie doesn't see or use groups from users like Confluence does. So any groups that you grant Opsgenie access to, the users are all just assigned the default "user" role. You can't even grant the "admin" role. If you're seeing something different I'd be very interested. Though I'm also using Opsgenie stand alone, not part of JSM, in case that makes a difference.

            @Stian, @Joel, @majken,

             

            What groups would be needed , and what permissions would we like for the groups? I can set this up through Atlassian Cloud with Push Groups from Okta much like we do for Confluence. 

            Dakotah Jackson added a comment - @Stian, @Joel, @majken,   What groups would be needed , and what permissions would we like for the groups? I can set this up through Atlassian Cloud with Push Groups from Okta much like we do for Confluence. 

            Provisioning / deprovisioning of users and setting user roles for OpsGenie through Atlassian Access / Atlassian Admin site would be really nice. Its annoying that you have to grant users product access through Atlassian Access, but then you need to manually create and assign user roles for the user in OpsGenie, that means you also have to manually remove them from OpsGenie if that user leaves the company.

            Stian Bentsen Sveen added a comment - Provisioning / deprovisioning of users and setting user roles for OpsGenie through Atlassian Access / Atlassian Admin site would be really nice. Its annoying that you have to grant users product access through Atlassian Access, but then you need to manually create and assign user roles for the user in OpsGenie, that means you also have to manually remove them from OpsGenie if that user leaves the company.

            The ability to have groups to be stakeholders is key. We want to ensure our business users can view key notices in OpsGenie, but right now admins have to crawl the list and change roles by name. 

            Joel Vasallo added a comment - The ability to have groups to be stakeholders is key. We want to ensure our business users can view key notices in OpsGenie, but right now admins have to crawl the list and change roles by name. 

            We're a fairly open organization and we'd like to grant more permissions by default than is currently allowed with the default User role. But since we can't change the default User role, we'd like users to be added to the custom role automatically instead. This isn't a case where we want to manually update some users but do it from Atlassian Access instead of Opsgenie. In this case manual steps are being required where we'd automate it if we could.

            Majken Longlade added a comment - We're a fairly open organization and we'd like to grant more permissions by default than is currently allowed with the default User role. But since we can't change the default User role, we'd like users to be added to the custom role automatically instead. This isn't a case where we want to manually update some users but do it from Atlassian Access instead of Opsgenie. In this case manual steps are being required where we'd automate it if we could.

              Unassigned Unassigned
              282e56b8661f Ashish Shetty J (Inactive)
              Votes:
              36 Vote for this issue
              Watchers:
              37 Start watching this issue

                Created:
                Updated: