Use these screens to set up user groups for Costpoint web and to establish module/application/result set security rights for user groups within the Costpoint web screens.
When the Use Web Security model for Client/Server option in the System Settings (Others » System Administration » System Settings) screen of Client Server is selected, the Maintain User and Maintain User Groups screens display all applications available for rights assignment (including those currently available in Client Server only). Also, when a user is added (or deleted) in the Web, that user is automatically added (or deleted) in Client Server. All user information common to Client Server (General Information, Workflow information, Company assignment) syncs up to Client Server automatically. User information specific to web is excluded (Printing Defaults, Authentication & Password information).
|
|
Note: Companies
frequently restrict access to these screens to system administrators.
|
The main screen contains a table window for user group ID and name data.
Three subtask links are also available from these screens:
Use the Assign Users to Group subtask to link one or more user groups to a user. This table window automatically displays along with the primary table window.
Use the Module Rights subtask to assign Read-Only, Full, or Deny rights in one or more Costpoint modules to one or more user groups.
Use the Application Rights subtask to assign Read-Only, Full, or Deny rights to a user group in one or more Costpoint applications within a module. You may, for example, have given a user group Full rights to a specific module, but want to assign Read-Only or Deny rights to one or more specific applications within that module. [You cannot assign Deny rights at a higher level and than assign Full or Read-Only rights at a lower level.]
Within the Application Rights subtask, you can also drill down to assign even more specific user rights, as follows:
Use the Result Set Rights by Application subtask (in the Application Rights subtask screen) to assign No Rights, Read Rights, Update Rights, Insert Rights, and/or Delete Rights to a user in one or more Costpoint result sets within an application. You may, for example, have given a user Full Rights to a specific application, but want to assign No Rights to one or more result sets within that application. (You cannot assign Deny Rights at a higher level and then assign Read Rights, Update Rights, Insert Rights, or Delete Rights at a lower level.) Use the Application Result Set Links subtask on this screen to view a list of applications that use the selected result set.
Use the Deny Action Rights subtask (in the Result Set Rights by Application subtask screen) to assign Deny Rights or Execute Rights to a user for one or more Costpoint actions (processes) within the result set. You may, for example, have given a user update, insert, and/or delete rights to a specific result set within an application, but want to assign or withhold execute rights to a specific action (process) within that result set. (You cannot assign Deny Rights at a higher level and then assign Execute Rights at a lower level.) Use the Application Action Links subtask on this screen to view a list of applications that use the selected action.
Use the Deny Report Rights subtask (in the Result Set Rights by Application subtask screen) to assign Deny Rights or Execute Rights to a user for one or more Costpoint reports within the result set. You may, for example, have given a user update, insert, and/or delete rights to a specific result set within an application, but want to assign or withhold execute rights to a specific report within that result set. (You cannot assign Deny Rights at a higher level and then assign Execute Rights at a lower level.) Use the Application Report Links subtask on this screen to view a list of applications that use the selected report.
You must establish at least one user group for each company before you can create any user ID in the Maintain Users screen (Administration\Maintain\Users).
If you plan to optionally assign a user group to a user, you should set up the user group first.
You may find, however, that the most efficient way to set up security rights for users is to first establish rights for user groups. Then, if necessary, you can use the Module Rights and other drill-down subtasks from the Maintain Users screen to override group rights for a specific user at the module, application, result set, or action/report rights by result set levels, as desired.
|
|
Note: You
can assign users to user groups in this screen OR you can assign user
groups to a user in the Users screen (Administration\Maintain\Users). |
You must have already established user information in the Users screen (Administration\Maintain\Users) before you can assign users to a user group in this screen.
Because you can establish security rights to each user group, a user assigned to a specific user group inherits the security rights of that user group.
What is the role of the "Everyone" user group?
The Everyone user group by default is initially set up to have full access rights to the User Preferences application (Administration » Maintain » Users).
By default, each user belongs to the Everyone user group, which therefore enables each user with the appropriate permissions (enabled in this screen) to modify individual choices in the User Preferences screen.
Is security shared by screens in Costpoint client/server and Costpoint web?
Costpoint Web does not share the same security tables as Costpoint client/server.
You must set up and maintain Costpoint Web security independently from the existing Costpoint client/server security.
Use the Maintain Users and Maintain User Groups screens (Administration » Maintain » Users) to set up Costpoint Web security.
How is the security level different for screens in Costpoint client/server and Costpoint web?
Costpoint web does not share the same security tables as Costpoint client/server.
You must set up and maintain Costpoint web security independently from the existing Costpoint client/server security.
Use the Maintain Users and Maintain User Groups screens (Administration\Maintain\Users) to set up Costpoint web security.
In Costpoint client/server, security rights are defined at the module level. Application rights are inherited from module rights unless overridden at the application level.
In Costpoint Web, similarly, rights begin at the module level and flow down to the application level. You can, however, also set up additional rights at more granular levels, including a Result Set level (a screen or subtask within an application), and specific rights below the Result Set level, including specific Action or Report rights within the result set.
What is the relationship between a user and a user group?
In Costpoint client/server, a user can only be assigned to a single user group. The rights granted for the user group are automatically inherited by the user unless they are specifically overridden at the user level.
In Costpoint Web, a user group acts as a role. You can assign an individual user to one user group, many user groups, or no user groups. Rights granted for the user group are automatically inherited by the user of such group unless you have explicitly defined rights at the user level as an override.
How are conflicting rights resolved by the system?
When a user has his own rights and belongs to a group or multiple groups, rights are additive across the user and user groups except when rights are set to Deny. Deny rights override other rights assigned to that user and to the user groups linked to that user.
For instance, if a user is given Full Rights to a specific application but the user is also linked to one or more user groups that have Deny Rights assigned for the same application, the user cannot access that application.
Other rights (i.e., non-Deny rights) are considered additive. If a user is assigned Read-Only Rights to an application but his user groups are given Full Rights to the same application, the user has Full Rights to that application.
Application rights set at the module level are inherited at the application level. You can set an override at the application level for one or many applications in a module. Once you have explicitly set rights for an application, such application rights will be used and module rights inherited from any other groups will be ignored.
If application rights are explicitly set for the user and user groups, those application rights are resolved together using the Deny vs. Additive rule explained above.
Result Set rights determine the specific activities a user can perform within a given result set. A result set can be a common screen used in more than one application. In such cases, the Result Set security applies to all applications that call that result set.
You can grant rights for any or all of the following actions: Insert, Update, Delete, and Select.
If Result Set rights are not explicitly set, the following default rights are inherited from Application rights:
If a user has Deny rights to the application, the user cannot access the application and the user has no Result Set rights.
If a user has Read-Only rights to the application, the user has Select rights for the result set.
If a user has Full rights to the application, the user has all Select, Insert, Update, and Delete rights for the result set.
If Result Set rights are explicitly set, they cannot enhance the default rights from the Application (default rights); they can only be set to reduce those default rights.
For example, if a user has Deny rights to an application, that user will not be able to view any result sets from within that application, regardless of the user's Result Set rights. If a user has Read-Only rights to an application, that user will not be able to modify data in any result set from within that application, even with Full rights to the result set.
Within a result set, you can give users rights to individual actions and/or reports linked to that result set.
If these are not defined, the following default rights are inherited from Application and Result Set rights:
If a user has at least Read-Only access to the application and at least Select rights for the Result Set, the user can run a report
A user must have more then Select rights to the Result Set in order to be able to invoke its actions. Any additional right such as Insert/Update/Delete will be sufficient for running actions.
One exception to the rule above applies to result sets which are not editable by design. In these cases, it is impossible to have more than Select rights for the result set since it was not designed/developed for modification purposes. If an action exists for such result set, a user will always be able to run it unless his rights for running the action are explicitly revoked at the action level.
By using rights overrides at the Action level, you can either allow a user with Read-Only RS access to invoke an action or deny rights for a user with modification rights to run it.
By using rights overrides at the Report level, you can deny rights for a user to run a report even though the user may have rights to view the result set.
What happens if no rights are set up for a user group?
You do not need to explicitly specify security rights in the database at each of the three levels in order to fully view/access applications and result sets:
If no Module rights are set up for a user or any of the user groups to which the user is assigned, the user will not be able to access that application.
If no Application rights are set up for a user or any of his user groups, Module rights will be used.
If no Result Set rights are set up for a user or his user groups, Application rights will be used.
In which order should I set up screens when setting up a new user group?
Report Locales
System Printers
Employee User Flow
Company Taxable Entity Information
Org Security Groups
Users
Use the fields in this block to add new user group IDs and names or to edit the user group name for existing user group IDs.
Enter up to 18 alphanumeric characters to specify a new user group ID or use Query to select an existing user ID.
Name *
For a new user group, enter up to 30 alphanumeric characters to designate the user group name.
For an existing user group, you can edit this data as desired.
* A red asterisk denotes a required field.
Use this subtask link to open the Assign Users to Group subtask.
Use this subtask link to open the Module Rights subtask.
Use this subtask link to open the Application Rights subtask.
Changes to these screens update the following tables:
W_USER_UGRP_LIST (User Group List - Web)
W_USER_GRP_USERS (User Group User - Web)
W_USER_COMPANY (User Company - Web)
W_MODULE_RIGHTS (Module Rights - Web)
W_APP_RIGHTS (Application Rights - Web)
W_RS_RIGHTS (Result Set Rights - Web)
W_ACTION_RIGHTS (Action RS Rights - Web)
W_RPT_RIGHTS (Report RS Rights - Web)
