Organize content: Using Subwikis or Spaces

Help / Discuss
1

Hello guys,

we are currently in the process of introducing XWiki in our organization and are trying to decide on the best way to structure our content.

We are an organization with multiple business units, each of them having their own content. Our requirement is that employees from one business unit should not be able to see the content of other units.

Now, we see two possible approaches:

  1. One main wiki with spaces and permissions – All content lives in one wiki, but access is restricted via groups and permissions so that each unit only sees its own content.

  2. Separate subwikis per business unit – Each unit gets its own subwiki, which would naturally enforce separation, but comes with additional overhead since every subwiki needs to be configured and maintained (extensions, email integration, etc.).

Our main concern is the administrative overhead: with many business units, managing multiple subwikis could become very time-consuming. On the other hand, a single wiki with many spaces requires careful permission management to avoid accidental data leaks.

So my questions are:

  • What is considered best practice in XWiki for such scenarios?

  • Do larger organizations usually go with a single wiki and structure everything with spaces and groups, or do they prefer separate subwikis?

  • Are there common pitfalls we should be aware of with either approach?

Thanks a lot for your insights!

2

Something that could help: https://www.xwiki.org/xwiki/bin/view/Documentation/UserGuide/Features/ContentOrganization/ and especially https://www.xwiki.org/xwiki/bin/view/Documentation/UserGuide/Features/ContentOrganization/WikiVsNestedPages/ which tells you what is supported or not by each option.

For ex if each business unit needs to have the power to install the extensions they want, you’ll need a subwiki approach.

1 Like
3

Hi @Florian1

Did You ever look into this - We have Confluence Data Center with customers - and cant migrate to cloud, due to customer accounts being able to see each other

So - last week I set my eye a bit more on XWiki and the sub-Wikis - but we will need 100+ Subwikis at least.

1 Like
4

Hi! Great topic and good questions!

I’ve been working on implementing and maintaining XWiki in my company for over 5 years.
Our company is mid-sized, with 7 business units.

Based on our needs and my previous implementation experience (I had worked with XWiki before), we chose the following approach to organizing content:

  1. Main Wiki – accessible to all employees. It contains general knowledge (instructions, regulations, tool descriptions, training materials, etc.) that are useful across all business units.

  2. Subwikis for each business unit – each business unit has its own subwiki where it stores working materials (requirements, test cases, work plans, …) and knowledge (instructions, training courses, documentation, …). These materials are specific to that business unit’s projects. Access to a subwiki is restricted to the business unit’s employees and administrators. Each subwiki has its own isolated database, which helps us meet information security requirements.

  3. Permissions model – the company uses Active Directory (AD) to manage users and groups. All tools, including XWiki, are synchronized with AD via LDAP. This way, we don’t have to manage user accounts separately in each tool – everything is handled in one place (AD). In XWiki, we use the LDAP Application to synchronize AD groups with XWiki groups.

Overall, this model is very convenient and fits our needs almost completely.
But there are a few points to keep in mind:

Restrictions inside a subwiki

If necessary, you can restrict access to specific project materials inside a subwiki by using space administration. BUT: when setting permissions for spaces inside a wiki or subwiki, you need to be very careful, because the access control system is complex. Use permissions instead of restrictions, since restrictions are very strict and affect many things. More details can be found in the access rights documentation.

This is why it’s usually better to give group access to an entire subwiki for the corresponding business unit’s team. That way, you don’t have to configure permissions manually as much.
We concluded that restricting access to project materials inside a business unit’s subwiki should only be done in exceptional cases, when it’s truly necessary. Within a business unit, project teams communicate with each other, and people often move between projects. If you restrict access at the project level, you’ll create a lot of extra work for yourself in terms of configuration and maintenance.

Search

If you want search results to respect access rights, you’ll need to configure this.

Content reuse

We have a knowledge management system. Its processes assume that knowledge from business unit’s subwikis should be “promoted” to the Main Wiki level once it becomes useful for the majority of employees. In this case, instead of copying and duplicating material, content reuse should work.

XWiki has an extension for this – Display Macro. However, it respects access rights. So when promoting knowledge from a restricted subwiki, it becomes useless. Display Macro needs a feature (a checkbox) to ignore access restrictions, so it could be properly used in a Main Wiki + subwikis model. I’ve created a topic about this on the forum.

These are the main points regarding your question.
Good luck with XWiki!

5

Hello,

Very interesting feedback, thx.

Search should obey access rights by default. What did you have to configure?

Definitely!

I’ll check the thread but we cannot do this. This would be a security violation. If a document is supposed to be visible by others then simply set rights on it so that it’s visible. Or maybe better, move the content to the main wiki and create a redirect to the main wiki (this a checkbox to check when moving the page).

Hope it helps
thx

6

Hi @hrapitan !

Thanks a lot for sharing your experiences from your company. It really shows how extensive XWiki’s features are and the many ways it can be used. The topic is quite relevant for us right now. Just last week, our steering committee decided that we will use only a single wiki for our entire company.

We’re taking it even further: we want to remove all restrictions and make every piece of content visible. Our user roles are Reader, Editor, and Author. For our approach, it is essential that only pure knowledge is stored in XWiki. To ensure this, we are currently working on a strict guideline clarifying that no personal data, nor any supplier or customer information, may be stored.

We may be foregoing some valuable features that XWiki offers, but by doing so we avoid additional operational overhead and eliminate the risk of creating impermissible connections. Should the need arise to set up dedicated subwikis, I look forward to being able to draw on your insights again.

That’s where we currently stand. I’m curious to see how our XWiki will evolve. All the best to you, and thanks again!

7

Hi Vincent!

About search:
I didn’t formulate it precisely before. I meant the “Indexing User” section in the administration panel – if you use this feature, you need to keep in mind that the results depend on the permissions of the user specified there.

Another peculiarity of the search engine: in earlier XWiki versions (13.x branch), we sometimes ran into a situation where users would see results from their subwiki (which is correct), but NOT from the main wiki, even though it contained content with open access. We solved this by reindexing, which helped.

About the Display Macro:
Your suggestion to configure access rights for individual pages makes sense, but it involves extra work – we’d need to submit a request to the admins (in our company this goes through a ticketing system) and then wait for it to be processed.

Moving content is possible, but then it disappears from the subwiki where it was originally created and where people are used to finding it. Quite often, content authors are against this scenario. And if the page/instruction is just a part of a larger reference section in the subwiki, moving it is completely unacceptable.

That’s why it would be simpler to lift the restriction inside the macro itself. My idea was this: a user who doesn’t have access to a page cannot even specify it in the macro’s “Page” field. So, only a user with access can add it. And if they check the option “ignore access restrictions”, it means they understand what they are doing. A warning message next to this field could highlight the implications.

I’m not insisting, of course – it’s just a suggestion for improving the macro, based on our real-world use cases :slight_smile:

8

Hi @Florian1

Glad to hear our experience caught your interest.
XWiki is actually a very powerful platform with huge potential!

You decided to use it simply as a Knowledge Base, storing only “absolute” knowledge with open access. That’s a reasonable choice, since it minimizes administration overhead.
But at the same time, you should realize that this approach limits many of XWiki’s possibilities.

In fact, XWiki can be used as a platform to manage all artifacts of the development process.
Here’s an example:

  1. Analysts write feature requirements in XWiki.

  2. Tasks are then created in JIRA based on these requirements. The JIRA tickets and the XWiki requirements are linked through cross-references.

  3. Git branches implementing the feature are linked to the requirements in XWiki and the JIRA tickets.

  4. Test cases and test checklists are maintained in XWiki, and they are connected to the requirements, Git branches, and JIRA tickets.

  5. Documentation describing the feature is also maintained in XWiki, linked to the requirements, test cases, JIRA tickets, and Git branches.

This way, you can build a system where all development artifacts are tracked and interlinked. On top of that, you can develop XWiki applications that aggregate this data and display it in dynamic views. This is extremely helpful for project monitoring and makes life easier for project managers and team leads.

Of course, this is a more complex way of using XWiki, and it requires careful access control for working materials – for example, by using subwikis.

I wish you success in implementing XWiki in your company! :slight_smile:

1 Like