Users

The "CPSUPERUSER" is a special administrative user.  No rights are explicitly assigned to him, although he automatically has Full rights to all of the modules, applications, result sets, actions, and reports by default.

A system administrator can log in as "CPSUPERUSER" to assign security rights to other users.

This user is still subject to all the same restrictions as a normal user (for example, password expiration, lockout, organization security, company assignment, and so on).

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.

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 Users screen (Administration » Maintain » Users) or the User Groups screen (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 a result set.

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, to many user groups, or to 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.

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 (for example, 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 such application.

Application Rights

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

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 is not 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 is not able to modify data in any result set from within that application, even with Full rights to the result set.  

Action and Report Rights Within a 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 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 deny rights for a user to invoke an action even if the user has rights to modify the result set.

• 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.

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.  

Report Locales

System Printers

Employee User Flow

Company Taxable Entity Information

Org Security Groups

System Settings

User Groups

Enter up to 18 alphanumeric characters to specify a new user ID or use Query to select an existing user ID.

Note:  The user ID can be the same as an existing user in Costpoint client/server, but there is no requirement that it be in the database at all.

As you enter the ID, each letter displays on the screen in uppercase, even if you enter it in lowercase. This ensures that the same sequence of letters and numbers will map to one Costpoint user ID. For example, if a user enters "smithj," "SmithJ," or "SMITHJ," Costpoint will assign the attributes of Costpoint user "SMITHJ" to that user.

Enter, or use Lookup to select, the user's name.  You can enter up to 60 alphanumeric characters in this field.  Lookup accesses the employee's name as it was entered in the Employee User Flow screen (People » Maintain » Employee), but you can edit this default as needed.

Your system administrator can, via check box selection in the Can Change Name check box in the Preferences User Can Change group box (in the Information tab), permit this user to change name data in the User Preferences screen (Administration » Maintain » Users).