Structure a knowledge base

Part V – Access permissions: Who is allowed to see the information?

16. December 2022

The concepts and structures chosen in the first four parts have impacts on the possible use of the wiki and thus also on the necessary configuration, for example around permitted and non-permitted access. Only in rare cases is every employee allowed to view all of the company’s data. In most cases, dedicated authorizations must be assigned.

Mediawiki default: access permissions via namespaces

The MediaWiki software regulates access to documents by default via the namespaces mentioned in Part IV – which ensures, for example, that guidelines can only be edited by authorized persons.

But the concept does not always fit. For example, it is difficult to protect all documents of a department with it. Therefore, many organizations decide to set up the permissions for their MediaWiki the other way around: There, administrators assign the namespaces to teams and workgroups and use the categories to mark the document types.

This approach may also be understandable and feasible, but it has serious drawbacks. Namespaces in MediaWiki are useful to set up a room for a group, for example, but the concept does not scale. As soon as a wiki has many groups, the administration of access rights to the namespaces becomes extremely time-consuming, which not least increases the risk of errors.

A more efficient solution: Flat authorization concepts in (sub)wikis

Even though the appropriate permission concept always depends on the individual use case, most knowledge bases primarily want to make content available for sharing, not lock it away. This is exactly where flat authorization concepts prove to be more advantageous than an organization along namespaces or categories, especially in the long-term perspective. To gain the necessary authorization protection for a critical team or departmental content, separate (sub-)wikis are a good idea (see figure 1)

Figure 1: Within the central knowledgebase, content can be divided into separate (sub-)wikis, for which different access rules apply

This allows HR staff to work in a separate wiki without having to worry about accidentally releasing logs or other internal application management information to unauthorized users, for example. In the central wiki with the internal knowledge base, you only publish the content that is important for everyone, for example, the employee handbook, vacation regulations, training measures, and so on. The management wiki is also neatly separated from the information that most employees need for their daily work.

(Sub-)wikis help, but avoid topic groups!

The basic structure of the wiki remains the same in the subwiki: Namespaces for document types and the categories for topic groups can be different at team level, but they do not have to be. You should avoid the “topic groups” as long as possible – they add another level of complexity that is not needed in most cases. Keep everything as lean as possible.

Planning versus proliferation: Spaces and (sub-)wikis

Setting up a new wiki must be done centrally and according to defined criteria, otherwise, there is a risk of what knowledge managers call the “Confluence effect”. Atlassian’s Confluence wiki software also relies primarily on so-called “spaces” to organize content. Any user can create Spaces with a few mouse clicks, which makes them very attractive for team work.

However, they quickly prove to be the horror of administrators: they quickly find countless Spaces that quickly become orphaned, and are thus confronted with the opposite of a collaborative knowledge base. The goal of working together on content and structured topics is thwarted by the massive growth of knowledge silos.

Best of both worlds: BlueSpice farm

BlueSpice farm is different: Here you get the advantages of both worlds. A central marketplace for knowledge and, where necessary, séparées in (sub-)wikis that can be set up without much effort.

Go to part IV
Go to part VI

Hallo Welt! GmbH is the company behind the open-source enterprise wiki software BlueSpice, which is distributed in more than 160 countries with over 1 million downloads. The Regensburg-based company builds collaborative software for knowledge management and online documentation since 2007.

Authors: RH/MF

Share This Story, Choose Your Platform!

Except where otherwise noted, news on this site is licensed under a Creative Commons Attribution 4.0 International license.

More BlueSpice News

  • Let’s have a short break
    over the holidays

    19. December 2022

    The Hallo Welt! GmbH will be closed due to Christmas vacation from the 24th of December till and including the 1th of January. You still want to contact us?

    Read more

    +
  • Access permissions – Who is allowed to see the information?

    16. December 2022

    Part five of our series clarifies the question of how access permissions can be implemented in a meaningful way. Via namespaces or (sub)wikis?

    Read more

    +
  • Categories, document types and namespaces

    9. December 2022

    In the fourth part, we bring structure to the company and assign departments and document types to the appropriate categories and namespaces. This approach is flexible and adaptable.

    Read more

    +