-
Suggestion
-
Resolution: Won't Fix
-
None
-
None
NOTE: This suggestion is for Confluence Server. Using Confluence Cloud? See the corresponding suggestion.
The feature announced here;
https://blogs.atlassian.com/2013/09/new-in-confluence-request-access-to-view-restricted-pages/
Which is the implementation of;
https://jira.atlassian.com/browse/CONF-28346
...means that a user can request access to a restricted page in Confluence. This has the potential to generate a great deal of spam to page owners, as people request access to pages to which they should not have access.
We have restrictions in place for a reason. So we don't want people requesting access to pages to which they do not have access. We require the ability to switch off the "Request access" feature.
With this feature switched off, should a user attempt to access a page to which they do not have access, they should simply be told that they do not have access. They should not be given the option to request it, or even to see who the owner of the page is.
Ideally it would be possible to enable/disable the "Request Access" feature on a per-page (including child pages) basis, as well as per-space, and system wide.
Temporary workaround
Disabling Confluence Administration > Manage Add-ons > System add-on > Confluence Request Access Plugin will disable the functionality and users will not be able to request the access to the page but will get a notification.
- relates to
-
- Gathering Interest
[CONFSERVER-33703] Provide ability to turn off "Request Access" functionality.
Ridiculous that this isn't a provided option. Users should not be allowed to request access to pages we have secured on purpose.
I receive every day requests for any tools, but we have a workflow. This is annyoing.
We have Jira Service Management and Jira Project as Premium but no option to do a simple config like "disable
Access requests". cant understand.
Atlassian is a dumpster fire of a company - how this feature cannot be toggled on or off is baffling.
I can relate to all the comments above. Despite the one telling to fire developers for writing that down - it's management decision, not developer decision to write a functionality in toggl manner.
We have an issue with this feature. We have own workflow and this functionality is against them and fact that you have to give admin for every manager so he could do a thing in Jira makes it even worse. Better solution for this case is fixing permissions level, so user can create boards etc without administrative level.
Please give us this feature. People are constantly requesting access that don't need access. We give access via AD groups and not via the app. The ability to send an automated response at the very least and automatically denying requests would be great. It's ridiculous that this isn't a feature.
I have to agree with the previous comments. There are things that from the administration point of view doesn't make any sense not having them. And it's unfortunate that after several major releases (and years) of Confluence these kind of basic features are yet not in place.
Are we expected to buy whatever third-party plug-ins to do something that Confluence must do natively?!
Don't take me wrong, I work with some Atlassian products for 6 years and I love it, but at this point I'd really hope to see more done on the basics...
The "close won't fix" response tends to make me believe those making the decision have never been the administrator of an extremely large instance, or multiples of them. This is not thinking at an enterprise scale. Most unfortunate decision to those who are their biggest customers. 
The resolution is that Atlassian doesn't think it is "too much of an issue", so they are not going to provide the ability to disable. It is irresponsible of Atlassian to allow their developers to create new add-on (non-core) features without a mechanism to disable. There is a System App named "Confluence Request Access Plugin", but like all system apps/plugins, Atlassian indicates that disabling may cause Confluence to become inoperable.
Hey Atlassian – Why don't you have your developers evaluate the consequences of disabling this app/plugin and provide guidance if this plugin can be safely disabled? And if it can't be disabled, fire the developers that did this and have others make this plugin so it can be disabled. Of course, you can continue with your normal mode of operation.
edit – tried to add image, but didn't work, so imagine a picture of an ostrich with it's head in the sand.
What a dumpster fire