-
Suggestion
-
Resolution: Unresolved
-
305
-
Problem Definition
The feature is to provide a way for existing users to Requests Access to another product (within the same site) that they don't have access to, and to allow existing users to Request Access for new users.
Note: This feature does not allow users to self signup, but to only request access via an Admin. The existing 'Users can invite other users' checkbox in the Site Access settings, allows a user to invite another user without any Admin approval.
Suggested Solution
Improve Request Access to allow Admins to:
- Configure the 'Grant Access’ button to give access to default groups + custom groups / projects
- Allow admins to receive the notifications in the system, and/or define a particular group to receive the notification (so not all site admins have to receive it)
- Handle duplicate requests for access correctly (i.e. only show one request)
- Remove requests for access if the admin grants access via Groups, the User List or User Details page
- Create an additional option to ignore the request in cases where the administrator does not want to revoke this access forever.
- Provide additional options in the User Invites settings, to allow for more flexibility. e.g. Invites to approved domains without any Access Request ability.
- Ability to disable the access request to products when organisations have a defined process of provisioning access
Currently in development:
- Nothing
Completed:
- Provide a better indicator on the Admin page that there are pending access requests
- Update the "Grant Access" and "Deny Access" buttons to reflect what they actually do, "Approve Request" (which adds the product access) and "Deny Request" (which does nothing to any existing product access, but just denies the request...)
- Fix the pagination issue for large lists of requests
- https://jira.atlassian.com/browse/ID-6651 - Allow notifications to be more flexible for each domain added.
- https://jira.atlassian.com/browse/ID-7692 - Allow admins to turn this off completely if it doesn't fit their approval procedures
- causes
-
- Gathering Interest
- is duplicated by
-
- Closed
- is related to
-
ID-6734 Disabling the _Users can invite others_ tickbox still allows regular users to invite other people
-
- Closed
-
-
- Closed
-
- Gathering Interest
-
- Gathering Interest
-
ENT-1292 Loading...
- relates to
-
-
- Closed
-
-
- Closed
-
- Closed
-
- Closed
-
- Gathering Interest
- depends on
-
- is action for
-
- mentioned in
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
| Form Name | |||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
[ID-6682] Improve Request Access feature
If this feature is provided, installations should have control over who can request what and for whom. In other words self-nomination and nomination of others should be allowed or disallowed on an installation-wide basis.
With nothing currently in development by Atlassian to address these issues, we've released an app to put some automation into admins hands to better control product access. With the Admin Automation app, it doesn't matter which invite or user access setting you have turned on, you can automatically remove product access for any user if they're not in one of your 'key' groups. The app will sync users from any group, into any other group, e.g.
- You can remove any user from jira-users-* or confluence-users-*, if they're not in your special 'All users' group. This is a simple and quick way to ensure new users can't get access/invited to any products without being in your 'key' group.
- You can sync an IdP group into any of the Atlassian default product groups.
- You can sync users from the jira-users-* group into the confluence-users-* group, ensuring that Jira users always have access to Confluence as well.
Hopefully it can help some of the people on this thread!
-Kieren
Co-Founder @ Smol Software | Ex-Atlassian
How did you "disable the access request feature"? I would like to do that in my site, but you are the only one mentioning this is possible.
Any way this can get moved from "consideration" to "New feature request?" We need this enabled as a company in order to properly follow our security protocols. People constantly request access by going around our service desk team. In doing so, requestors are not getting access as needed. We do communicate to employees that they need to request access through service desk however sometimes info isnt communicated to new hires. We set users up in our domain for security purposes therefore need this turned off. I have updated that only admins can provide access but that doesnt disable them from requesting access using the request through jira.
@ Roland Schroth added a comment - 30/Aug/2023 10:29 AM
We disabled the access request feature.
How did you "disable the access request feature"?
We disabled the acceess request feature. Now I am stuck with existing access requests that I neither want to approve or deny (because users either already have the access by now or not, for reasons). I would really appreciate a way to simply get rid of those requests, so nobody will have a chance of accidentally approving any of them.
Just deleting a request should do no harm and still allow possible future requests (in case the feature is activated again by admins).
I hope that this is introduced as an optional function.
We dont want anyone requesting access as have a process with ticket raised as we done let just anyone access as keep a tight reign on our users.
Last time something similar happened my workload was increased as had to contact and say why access was not allowed whereas in our process there is an automatic response to the teams who will not require access.
It would be even good to make the link customizable. So that the user can click on it to open an access request ticket via our portal.
At the very least add a comment field to the form so that the user is forced to add some context to their request.
Happy New Year, everyone! May it be filled with joy, success, and - who knows - maybe even some miracles. Like Atlassian resolving to fix this bug. We can dream, right?