-
Suggestion
-
Resolution: Won't Fix
-
None
-
None
NOTE: This suggestion is for Confluence Server. Using Confluence Cloud? See the corresponding suggestion.
In big organisations, a lot of spaces can be created and it's then required to have a parent-child relation between spaces.
The child permissions could inherit from its parent. In this case, it should be a true inheritance (not a copy). The child space should be able to specialized the inherited permissions.
- is duplicated by
-
- Closed
- is related to
-
- Not Being Considered
- relates to
-
- Closed
-
- Closed
[CONFSERVER-1411] Hierarchical spaces
Aditya Gaddam
added a comment - Sometimes you don't want to create multiple spaces and link them together. Because in the end, you still have the URLs being detached. What we want to do is have
Project/VersionA/Introduction
Project/VersionB/Introduction
With the current setup, URLs can only be Project/Introduction. So nested spaces won't really work. Unless we start having to name spaces Project Version A, Project Version B. This just seems like a lot of unnecessary verbosity. It also leads to problems with linking to JIRA projects. Do we just link the top space and all the nested spaces get linked? Or do we link each sub-space?
Wouldn't it be better to do something about the Space->Page mapping? The database seems to map them via ID and there is even a hierarchy. It just seems like the UI is doing silly things to force a flat hierarchy. For example, why are <ac:link> tags using Page names? Why don't they just IDs. The IDs don't change. Seems hell of a lot nicer to link using that. It would also take away any need for page names to be unique. Why are language/encoding dependent strings being used to maintain any sort of relationship?
And it seems pretty clear that there is a LOT of interest in having REAL hierarchical pages in a space. Not just fake navigation menu stuff. Even more confusing is that if we have things like Project/Version A/Introduction A, Project/Version B/Introduction B (to get around the unique page name problem), the resulting URLs are just stupid, because they end up being Project/Introduction A, Project/Introduction B. How is this clear to anyone using the site? People like hierarchies. Why is there a flat model being enforced? People who want flat models can easily use it that way. More importantly, it doesn't seem like there is any massive technical reason this is not being done.
Aditya Gaddam
added a comment - Sometimes you don't want to create multiple spaces and link them together. Because in the end, you still have the URLs being detached. What we want to do is have
Project/VersionA/Introduction
Project/VersionB/Introduction
With the current setup, URLs can only be Project/Introduction. So nested spaces won't really work. Unless we start having to name spaces Project Version A, Project Version B. This just seems like a lot of unnecessary verbosity. It also leads to problems with linking to JIRA projects. Do we just link the top space and all the nested spaces get linked? Or do we link each sub-space?
Wouldn't it be better to do something about the Space->Page mapping? The database seems to map them via ID and there is even a hierarchy. It just seems like the UI is doing silly things to force a flat hierarchy. For example, why are <ac:link> tags using Page names? Why don't they just IDs. The IDs don't change. Seems hell of a lot nicer to link using that. It would also take away any need for page names to be unique. Why are language/encoding dependent strings being used to maintain any sort of relationship?
And it seems pretty clear that there is a LOT of interest in having REAL hierarchical pages in a space. Not just fake navigation menu stuff. Even more confusing is that if we have things like Project/Version A/Introduction A, Project/Version B/Introduction B (to get around the unique page name problem), the resulting URLs are just stupid, because they end up being Project/Introduction A, Project/Introduction B. How is this clear to anyone using the site? People like hierarchies. Why is there a flat model being enforced? People who want flat models can easily use it that way. More importantly, it doesn't seem like there is any massive technical reason this is not being done. Hi Guys, How does this differ to the nested spaces issue? CONF-1095
Richard THIBAULT
added a comment - Hierarchical spaces is the only feature that need to be added so that confluence can replace a forum tool
Richard THIBAULT
added a comment - Hierarchical spaces is the only feature that need to be added so that confluence can replace a forum tool 
Hi Guys,
Given that we've got https://jira.atlassian.com/browse/CONF-1095 which covers the bulk of the issue, I doubt we will go much further than that. And given that this has been open for several years with little traction I'm closing this as Won'f fix. Instead we would consider implementing features like CONF-1095 instead.