This article will explain a little about the idea of justifying user groups, depending a little on the Q-DAS products used.
There are 2 basic errors that customers make in user management:
- Too few groups are created
- Too many groups are created
Groups should be created for reasons. Reasons could be different authorisations that are allowed, various system settings that are set per group, and depending on the products and their capabilities. The article attempts to provide an initial insight, without any promise of completeness. The structure of the article is based on more and more products being used. The user groups delivered by default (as a first introduction) are not taken into account for the time being.
A Recommendation: Start with less groups as possible. Create new groups if needed only. A trigger could be, that you would have to start to make a configuration for one specific user!. This is then a trigger to think about new groups.
User group Systemadministrator
For the time being, there is no reason to create additional "persons" in the "System administrators" group. A distinction must be made here between "functional users" and usernames that reflect a person. The system administrators group should be reduced to these "function users".
ConfigurationUser: This user is responsible for all configuration in terms of configuration management.
SuperUser: This user is to be used exclusively for setting up the upload and the reporting system.
A further function user can be added here as an idea. The "filter user"
With this user, the key user can create filters which are made available to user groups.
Now some will say: Why such a user? Surely colleague XXX can do that? Or can all filters created by the configuration user be made available to all users?
That is correct so far. It depends on the number of users and user groups. With many groups and hundreds of users, the number of filters for the configuration user can become unmanageable at some point. With several key users per plant, it also becomes critical to make the high login of the configuration user available to many key users. But never should a user of a "person" create filters for groups. This is because if the user is missing or even leaves, it would be almost impossible to edit this configuration. It would then only be possible to delete the configuration and set it up again.
User group „Administrator / Key-User“
Why another group of administrators? Quite simple. It depends on the size of the company. Let's follow the rule of the system administrators group, in which there should be no people as users (for security reasons), and especially if there are several key users, it makes sense to create a separate group here
Members of this group may be allowed to do many things, but they are not allowed to change the evaluation strategy, for example. They are also not allowed to see the system administrators group in this login, create new groups or change authorisations. But they can create users in existing groups, provided they still have the user management authorisation.
User Group: „Former employees"
It is recommended not to delete former employees or function users. In the FDA environment, there is even a requirement, which can be activated as an option, that users may not be deleted once they have been created. The users may have been used to record data or make configurations, and deleting the users would make them untraceable. Therefore a group is created ‘Former employees’, without rights.
Users who are moved to this group are then blocked so that it is no longer possible to log in with this username.
User group „Evaluators“
For the user groups of the "evaluators", 2 groups are created in most cases, which differ in their authorisations.
Evaluation
Standard Evaluation
These users make analysis. Not data collection, they make the analyses. The differences are in the user-rights.
The difference does come from the training. A “Standard-evaluator” just had a basic training. He knows how to make the interpretation of the results. But only with a deep training, a yellow-belt, green-belt, detailed training and knowledge, a user knows what it means also to change a distribution, change QCC-parameters.
Als for the Raw data a difference can be made between the groups, when a “Standard-evaluator” should not be able to collect or change values / additional data / parttypes..
User groups Evaluator due to pre-filtering
The larger the number of users, the more often customers ask how to grant users access exclusively to their part types so that they cannot see part types that they should not/may not see.
Here, a complex filter at part type level can be placed upstream of a user group:
This would therefore be a reason to split the groups of evaluators into various groups in order to define each group's own pre-filter:
User group procella-data collection
Using the example of procella: O-QIS users must be in their own user group.
Authorisations can be reduced to ‘Enter measured values and additional data’, for example,
saving back to the database, seeing all ‘part types’
And the user right to ‘Load user-specific settings’ should be removed, as data collectors should not have the right to use their own settings. Their configuration should only be given to them via the configuration management of the groups.
User groups procella data collection due to pre-filtering
The same idea can be used for data collection as for evaluation, namely that there must be several user groups that are given a pre-filter so that they only see the part types that they are authorised to see.
User groups procella data collection due to configuration data collection
Now the fun part of this documentation begins. It is very often necessary to create different user groups for the different data collection configurations and the different views that are required. A layout is then assigned to each user group in configuration management and the ‘Data collection configuration / standard’ is defined.
But what happens if a user works in a rotating system in the company? For example, the user ‘Maija Meikäläinen’ is moving from Hall 1 to Hall 2 every week?
It would make no sense to constantly move users who work at different workstations in a rotating system in your company to other groups just so that they can use their configuration.
For procella, there are 2 variants for using test plans with a specific configuration and layout. One is the configuration of the user group settings:
This means that every test plan that a user opens a group is recorded with exactly the graphics and settings of the user group.
The other variant is to define configurations and the views (setup data recording and the 10 available ‘Summary/input’ graphics) as the default, shown here using the example of the templates:
Each test plan can then be given the templates for data recording and the desired view:
This means that every test plan works regardless of the user's settings or user group.
The decision on which type of configuration deployment to use should be planned in advance, taking into account the personnel situation.
User Group “Windows-User”
For an easier usage, the user group “Windows Login” can be created, and the Windows-User Login activated
This group maybe can have NO user rights, and only the first start of the software create the windows-User directly in this group. Afterwards, the Key-User can move the Windows-Login to the group he should be in:
