My mistake, did not realise I was in a server ticket. 

My issue with setting up a new space per collaboration project is that it would result in the creation of 50+ spaces every year. 

Ill take my thoughts over to cloud. 

Hi Alex,

there're addons on the marketplace for server allowing to share a page via an external URL, but they don't allow editing /commenting the pages. This issue is specific to Confluence Server. Cloud is another product & I'm sure there is a specific ticket for Confluence Cloud (http://jira.atlassian.com/browse/CONFCLOUD-7089)

You can (and should) always organize a Confluence environment as you mentioned in your answer (Specific spaces for external collaboration etc.) but this can be done without the need to enable a specific page to be view/editable by someone otherwise having no access to the space (and therefore missing a lot of context around the page).

Hi Jan-Peter, 

Thanks for your thoughts. I know it's easy to say but many other collaborations tools offer the ability to collaborate on a specific environment. While they have positives and negatives on different platforms I do feel the ability to collaborate with people outside of your organisation is essential. 

In response to your questions:

• If a handling of permitting viewing/editing a single page is implemented, how should a user find this page apart from a link to this page or a shared URL? Imagine the space itself is not visible for the permitted user, what information should be exposed, when he opens the page. Maybe the space title itself is classified for the permitted user. Yes a shared URL. The only information that should be displayed is down tree from the page that has been given access. Allow in the UI for access to multiple branches if needed. Ability to switch between organisation already exists if needed. 
• Speaking of a Confluence instance with round about 85.000 pages: Who is responsible, if a single user opens a page for a larger audience? What happens, if the permitting user is leaving the company? I've not solution to this administrative nightmare. Right now the implemented handling is pretty straightforward: Permissions on the space level, restrictions on the pages. These are easy to handle & to explain rules for users which are new to Confluence & for administration. There is a common misunderstanding that permissions can be set on pages. This is not true, they can only be restricted. With a confluence instance of 85000 pages does it not make sense to grant outside access with a fine brush as opposed to a whole space? Organisations can set a specific space for outside collaboration.  In this space users can create new pages, with a down tree of pages for additional content. Outside access can be given by the owner at the level of page they own. Outside access can be removed at any time but also has a sunset timer that will disable access after a certain period. Outside access can not own a page and can not give additional access. 

IF ANYONE ELSE ON CLOUD IS LOOKING FOR A SOLUTION WE HAVE FOUND EXTERNAL SHARE  SEEMS TO BE SUFFICIENT FOR OUR NEEDS

Outside users have the ability to upload and comment, but not edit pages. 

Adding to one of my earlier comments on this issue, I still see a change in the space permission / page restriction scheme as a two sided sword from an information security point of view.

Some questions arise:

• If a handling of permitting viewing/editing a single page is implemented, how should a user find this page apart from a link to this page or a shared URL? Imagine the space itself is not visible for the permitted user, what information should be exposed, when he opens the page. Maybe the space title itself is classified for the permitted user. 

• Speaking of a Confluence instance with round about 85.000 pages: Who is responsible, if a single user opens a page for a larger audience? What happens, if the permitting user is leaving the company? I've not solution to this administrative nightmare. Right now the implemented handling is pretty straightforward: Permissions on the space level, restrictions on the pages. These are easy to handle & to explain rules for users which are new to Confluence & for administration. There is a common misunderstanding that permissions can be set on pages. This is not true, they can only be restricted.

Restrictions on pages are, by the way, a good and fast way to bring Confluence to it's performance limits, even more when you start reusing content embedded from other pages or using reports. As you see by the creation date of the ticket & the comments written in all the years & the linked tickets to this issue, it's a topic discussed a lot over the years with no easy solution. Sometime thinking about how content is ordered / structured in a space solves many problems.

If this function is ever implemented in Confluence: Atlassian, please make the function configurable or restrict it to a new space permission, which can be assigned to users and/or groups.

Reading thru the comments I would like to add, that also edit restrictions should be inherited from parent pages, not only the view restrictions. This would solve many problems.

+1

is there any update on this issue?

It's been now more than 13 years since this issue was created and more than 1 year since the last update.

Please Atlassian give us at least an update, if we can stop hoping this will ever be done.

Greetings, would you provide an update on this? Not having this basic functionality severely limits the use cases we have for Confluence, which is hard for me to say as our organization's internal champion for your product.

+1

Hi!

It is exceedingly annoying to have to give users way more access than they should have just because one want it to be possible for them to edit or add subpages to a certain page .
It significantly reduces the possible use cases for Confluence in our (pretty large) organisation and is an implicit security issue as it pushes users in the wrong direction.

I agree with comments on the slightly incredible length of time this has not been done without any real explanation on why it has not been done yet.