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.
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.
@Sam Knight Is there any way through which we can restrict issue creation for a specific Issue type from agent portal which should not impact on Customer Portal? From customer portal user can create any type of issues. but from agent portal he should able to create only specific issue type
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.
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.
How has the recent change to support restrictions by customer/organization not been more widely distributed. I saw the original post and was dying for this recent addition.
@Sam Knight what about restricting something to "Portal Only Accounts". We have situations where we want to restrict the request type to our external customers, and not internal users that are accessing the portal with the Atlassian account.
Right now, we would have to explicitly share the request type with every organization or customer to prevent internal users from seeing it. Happy to discuss the use case offline.
Is it still the case that the issues can't be raised by chat/assist if the group has access specified in the restriction? Our use case is that we need HR to have access to specific IT ticket types and not all users.
@Steve Fitzgerald I think that is the case. I broke our Slack integration for our entire internal IT Helpdesk over the holidays by adding request type restrictions. It took me a while to realize this is what caused it, and Atlassian later confirmed in a ticket I opened that Slack visible request types cannot be restricted (full stop).
47 comments