The Permission Manager: Rights management in BlueSpice pro
4. June 2019
In short interviews with our employees, we bring you closer to questions from everyday work with BlueSpice. This time the topic is about rights management with the Permission Manager. An interview with Florian Bäckmann, responsible for technical support at Hallo Welt! GmbH.
Florian, wikis are essentially open and transparent. Why assign rights all of a sudden?
“That is true. Actually, wikis are based on the “wisdom of the masses” and are virtually a virtual public domain. Basically, everyone participates and the content is usually public.
But with our wiki BlueSpice we serve corporate customers, i.e. the enterprise segment. And there, rights definitely play a central role.”
But shouldn’t knowledge silos be broken down with the help of a wiki and company knowledge be stored centrally?
Correct. But central is not always central. Our customers usually know where the bottlenecks and pitfalls of accessing a company-wide knowledge database lie. Between the two concepts “everybody is allowed to do everything” and “everything lies with one or a few employees” there is a large playground, which we serve with our Permission Manager.
Can you explain that in more detail?
Sure. On the content level, for example, it is often the case that individual rights are needed for departments, working groups or project teams, for example to change articles. Another example: the management. Here there are usually separate areas (namespaces) which are provided with privacy protection. Finally, sensitive information is also exchanged here.
If a business wiki is public or semi-public, sophisticated rules are usually required to prevent abuse. And then there is the technical-functional level: Imagine that every wiki user would have admin rights and could change central settings. Chaos would be pre-programmed. That’s why there are also extended rights for appropriately qualified employees or IT administrators.
With BlueSpice 3, the assignment of rights has been revised. Why is that?
It turned out that the assignment of rights in BlueSpice 2 was not very intuitive and was too complex to use for many customers. Since almost every function in the wiki is linked to a right, more than 200 individual rights could be assigned individually at that time. With the launch of BlueSpice 3, we therefore introduced the so-called role system. The main goal was to significantly simplify the assignment of rights. Speaking of complicated: While MediaWiki allocates rights via a file stored on the server, BlueSpice offers a graphical user interface that allows rights to be assigned or adjusted quickly and easily by simply placing a few check marks.
That sounds good. But how exactly does the assignment of rights work?
First of all it is important to distinguish between users, groups, roles and rights. Furthermore, a basic distinction is made between anonymous wiki visitors without an account and registered wiki users with an account. First, a group already existing in the system or created by the customer himself is linked to individual wiki users, mostly employees. These are then assigned to a group.
The groups are then assigned rights packages with the help of so-called roles. Here, individual roles bundle numerous individual rights under one meaningful roof. The rights can be assigned wiki-wide or for individual namespaces (e.g. different rights for employees in different departments of the company).
Typical roles are:
- Reader: may read and comment on content
- Editor: as above, may edit additional content
- Reviewer: as above, may additionally release content
- Administrator: as above, may additionally make settings on the wiki
Screenshot: Overview of the rights management in BlueSpice
Okay, got it. So it’s not exactly trivial to set up a rights system, is it?
I agree with you. Since the assignment of rights plays a central role in many companies, special attention should be paid to planning and configuration. Even though a wiki is essentially an open and transparent application, many companies have legal requirements and internal rules and regulations that make it necessary to restrict access. This applies to reading, but above all to changing information.
Screenshot: Insight into the individual permissions of a “role”, in this case, the editor
How do you then ensure that the rights system is set up correctly?
We offer our customers the “Rights Management Workshop”. Here we analyse and specify together the individual rights structure of the company wiki and assign e.g. group, read and write rights or the right to delete pages. The results of the workshop are systematically documented in a rights matrix, the customer wiki is then configured by our IT experts according to the specifications. After all, we want our customers to start with a wiki that exactly meets their requirements. Rights management included.
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. |