Modifying User Properties

---

User properties consists of three areas: user definitions that establish security levels and passwords, groups and profiles that control membership to groups and software, and timestamps that determine when a user can access the repository.

User Definition

To modify the user properties, select the user and click User/Group Properties.

The username is case-sensitive and can be modified here. It’s important to understand that user properties are global and apply to all instances of a user. If a user belongs to more than one group and his property is set to Disable Login, then he will not be able to access any universe. Table 12-5 summarizes each of the properties that you can control.

Table 12-5: User Properties Are Global and Apply to All Resources and Instances of the User

Option	Description
Disable Login	Prevents the user from logging into the repository. Generally used when employees leave the company or if a user has been defined to the repository but not yet trained.
Enable Offline Login	Allows users to work offline in a full-client environment, either when the repository is unavailable or when disconnected from the network.
Enable Password Modification	Users can change their own passwords for their BusinessObjects login. Warning: If the universe passes the login ID to the data source (Table 6-2, alternative 4), then users should not modify their BusinessObjects password as it may become out of synch with the data source password.
Enable Real Time User Rights Update	This option significantly increases the load on the repository. Normally, the universe version and available documents is checked only upon the first access. With real-time updates, any changes to the universe/document list are sent to the client PC when the user edits the data provider/retrieves documents. Use this option with caution, as it will increase overhead and is necessary only if your universe changes frequently. Note: this option does not work for three-tier BusinessObjects/ZABO.
Enable Delete Document	This box should be checked, as it allows users to delete documents from their Personal Documents folder in InfoView or to remove Corporate Documents they have exported.

Object Level Security

In Chapter 8, you left all the object definitions as Public. BusinessObjects offers five levels of column security: Private, Controlled, Restricted, Confidential, and Public (numbered 1–5 in Table 12-6). Object-level security allows designers and supervisors to restrict access to particular columns of data; it requires settings in both the universe’s object properties and the user definitions. The user security settings are global and not universe-specific.

Table 12-6: User Security Access Levels Interact with Universe Objects to Restrict Access to Columns of Information

Object Name	Security Access Level	Priority	User
Social Security Number	Private	1	Mary Olen, Peggy Eschbach
Salary	Controlled	2	All VPs
Bank Balance	Restricted	3	Finance Users
Profit	Confidential	4	Users > Three months
Amount Sold	Public	5	All

Private (priority 1) is considered the most restrictive; very few people would have access to such data, such as social security numbers or medical data. In Table 12-6, Mary Olen, the VP of Human Resources, and Peggy Eschbach, the Medical Director, are the only two users who have access to objects with a security access level equal to Private.

Salary objects have a security access level equal to Controlled. Users with an access level of Controlled or of a higher priority (Private) can access Salary objects. Profit-related objects are set to Confidential. Employees with their security access level set to Confidential (in this case, anyone who has been with the firm at least three months) can access the Profit objects, as can any users that have a higher-priority security level (Restricted, Controlled, Private).

These settings can be quite tedious to maintain. If you are not using them in your universe design or if you are restricted access at the database level, leave all settings in Supervisor Public.

To set the security access level on a universe object, use Designer, select Edit | Object Properties, and click the Advanced tab. Choose the desired restriction level from the drop-down box.

In Supervisor, set the security access level for each user that is allowed to access objects with security settings. In the following example, the VP of Sales and Marketing, Megan Michelle, has a security access level of Controlled. She will be able to see all objects except those with a setting equal to Private, as Private is a higher security level than Controlled. This applies only to universes to which she has access. For example, she still cannot see the Salary object, because it is part of a Human Resources universe that she cannot access.

Password Settings

The degree to which you use password settings depends on whether or not you are using unique logon IDs at the data source level (see Chapter 6). Through the Supervisor Password settings, you can force users to log in with a unique BusinessObjects username and password. This may be in addition to a unique or shared user ID for the data source. If you have unique data source login IDs, then keep the BusinessObjects security and password settings to a minimum to avoid conflicts with synchronization of data source passwords. Set the box Identification Strategy to No Password Checking.

Alternatively, if you use a shared data source logon, then you will want to require passwords within BusinessObjects. Leave the Identification Strategy at its default of Full Checking and complete the password selections. The password is case-sensitive and will appear as *s as you enter an initial, default password. Supervisors should always provide a default password; otherwise, unauthorized users can start BusinessObjects without any password.

Change Password At First Logon will force users to change their password the first time they use BusinessObjects. This ensures the supervisor does not know a user’s individual passwords. To force users to change their password periodically, click the box Password Validity and enter a frequency to force a password change—for example, 90 days. If a user enters an incorrect password three times, that user’s login ID is disabled and a sad face appears next to his or her name. In Figure 12-3, Brendan McConnan’s account has been disabled and he is locked out after he has entered his password incorrectly three times.

Groups and Profiles

Users can be associated with a group in one of two ways:

• Select the group, click User or Group Properties, and select the Users And Profile tab.

• Select the user, click User or Group Properties, and the Groups And Profile tab.

In the following example, a new user, Brian McLaughlin, was defined at the root or company level. He is a member of the group Plastics Express. To add Brian to another group, Sales and Marketing, select the name from Available Groups and click Add.

Users inherit a profile from the root level. Brian is automatically assigned a User profile within Sales and Marketing. To assign a different profile with access to the software modules listed in Table 12-3, use the Profile drop-down box to assign a different one.

Timestamp

Timestamps allow supervisors to control when users can access the BusinessObjects repository; users can continue to work offline with reports, but they are not able to create new queries or retrieve documents from the repository. Timestamps are best defined at the group level and not at the individual user level.

Caution 

Excessive use of timestamp control can slow repository performance in large deployments.

Disabling and Deleting a User

When you disable a user, the user cannot log into the repository. Many companies prefer to disable logins for new users until the user has attended training. Also, disabling a user retains all activity history even after a user leaves a company. Disabling is global and not group-specific.

To disable a user:

1. Select the username to be disabled.

2. Click Disable/Enable User.

3. Note the disabled symbol next to the user. In the Definition tab of the User Properties dialog box, the Disable Login check box is also now checked.

To reenable a user, follow the same steps.

I recommend only general supervisors delete users, as doing so removes all activity history and requires the supervisor to perform a repository scan and compact to physically remove the deleted user from the repository tables.

Tip 

Refer to the section “Software Functionality: Command Restrictions” later in the chapter to learn how to prevent decentralized supervisors from deleting users.

To delete a user:

1. Select the username to be deleted.

2. From the pull-down menu, select User | Delete User.

   

3. Supervisor will prompt you, “Do you really want to delete this user?” Click Yes.

4. The user will no longer appear in the Supervisor display; however, the user still exists in the Repository tables. To remove the user from the Repository tables, click the Repository button.

5. Select the Security domain and click Scan.

   

6. From the Scan and Repair dialog, click Compact to compress the repository tables and physically remove the deleted user from all tables.

7. Click Close to exit the Scan And Repair dialog.

8. Click Close to exit the Repository Management dialog.

   Caution 

   Only delete users when you no longer need an activity history for that user. Only general supervisors should delete users, as it requires a repository scan.

---