Atlassian Team members are employees working across the company in a wide variety of roles.
July 15, 2024 edited
Hey all - great to see the excitement for this!
To answer your questions:
When will this be available for me? For customers on release track, this feature will not be available until the next scheduled release. If you would like to be excluded specifically for this feature please email me and we will enable it for you now.
Restricting issue types. We have no current plans to extend this to restricting creation of issue types, but we have passed this on to the appropriate team in Jira.
Restrict by Teams and Project Roles. This is something we're looking into supporting, thank you for raising this, I'll keep this thread posted with any updates.
Excluding. Thank you for this suggestion! We have added this to our list of future enhancements for consideration.
While this feature is commendable, it seems half-baked to me.
For years this has been requested, even way longer in JSW for the issue type-level, and that still hasn't been provided. No company I worked for wants to pay (continuously) for app to provide such simple functionality.
But, the real problem is with "users and groups" only as the exception. Groups are not easy to maintain in Jira and Confluence (Atlassian Admin) and often still a very manual task to create and update, which means the contents of them are often stale.
Providing the option to use roles and the new Atlassian Teams seems like a first step in this and expanding Atlassian Teams to be allowed to use in Jira "People" (roles) and Confluence space permissions would be a natural next step to allow more granular access settings at the level of project/space administrator, taking some work out of the hands of the sys admin and power into the hands of the persons responsible for the content in the projects/spaces.
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
But this seems to affect visibility of the restricted request types for the Agents in our customized Queues: As soon as I give a specific agent access to the request type, the issues for this request type are visible again in the Queues.
Restricted request types can be raised in all channels except email, chat, widget, and the virtual agent. Any request types being used by these channels will no longer appear to anyone regardless of access if restricted. This is so anonymous users can still send requests via these channels.
The second and third sentence seems to contractdict itself: If request type is restricted it will no longer appear; however it is still available to anonymous users.
My requirement is to force users to login to the portal (so restrict request types), but still have it OPEN so anyone can email to create an issue.
@Andrea Hakim - You wouldn't be able to restrict an "Email" Request Type. That type should be hidden from your Portal anyway so anybody should still be able to email in to create a ticket.
35 comments