User Management Methods

Managing the users of the QPR system can be done in various ways, depending largely on the size of your organization. See the examples and notes below for choosing a suitable user management method for your organization. All the methods aim at providing the possibility of controlling all the QPR user management with the QPR User Management Client and the QPR Metrics/Modeling Clients.

 

To minimize the need of domain administrator involvement when defining user rights for QPR products, it is advisable to define group management to be handled with the "UMS only" option, as with the NT/LDAP authentication enabled the users can still use their NT/LDAP passwords, but the groups can be defined in the way that suits QPR products the best. Requirements for this concept are that there is one global group for QPR users in the domain and a corresponding group in the UMS to enable user imports. In the domain all the users are in the same group, thus relieving the domain administrator from the responsibility of having to administrate QPR user groups, as the groups concerning QPR products are managed solely in the QPR UMS. The QPR user groups are maintained by dividing the users in the GLOBAL_QPR group in QPR UMS (see the illustration below, the UMS GLOBAL_QPR group is synchronized with the domain's GLOBAL_QPR group to allow user imports) into groups that need different rights to QPR products.

 

 

Distributed Model Administration

In this method there is one (or more, if needed) QPR system administrator and the model management is distributed to different model administrators. This is a feasible method in a large organization with a vast amount of models in use. The QPR system administrator maintains the QPR system (handles upgrades and all the maintenance tasks) and grants user rights in UMS as well as defines model administrators. Model administrators take care of user rights within the model as well as all the administrative tasks within the models. Note that the model administrators should also have update rights to QPR User Management System to be able to define the users' e-mail addresses in order for the e-mail notifications to work.

 

Create groups for people who need different rights. One example grouping practise is to divide users into Administrators (a different group for Model Administrators can be used as well), Developers, Update, and View groups. Administrators are granted administrative rights in the QPR UMS Client, Developers are given Basic rights to QPR Metrics client and then their model-specific rights are defined in the QPR QPR Metrics. Update users can update information such as measure values through the QPR Portal. The update rights to measures are granted using the QPR QPR Metrics. It is also advisable to give the group update rights to QPR Portal as well, so that the users can bookmark the views they need to update often. The View rights group has only View rights to QPR Portal and Basic rights to QPR Metrics Web Client, so they can view models Portal, but are unable to modify them. The scorecards and measures they have rights to are defined in the QPR QPR Metrics.

 

You can also create a group for users who might need special rights for some occasions (such as having a measure that only a small group of people should be able to see), and in the case there is need for such rights, first add the user into the Exception group and then grant the group rights to the specific element or scorecard. The rights can be granted using the Scorecard Navigator. Select the desired element or scorecard, right-click on it to open the context menu, select User Rights from the menu and then either the Selected Object or Selected Branch option, depending on whether the rights are applied only to the element/scorecard or also to elements below it in the hierarchy.

 

Centralized Administration

In this method there are a few administrators handling both the QPR system administration as well as model administration. This method is feasible in smaller organizations with only a small number of models in use.

 

Similar group management as in Distributed Model Administration is recommended also here.