Make sure that you set the appropriate Default Group for the user. A user without a default group assigned uses the object views defined on the Object Views tab of the Designer application area System Settings.

If a default group is selected, the user uses the object views selected on the Object Views page of the group account. You can select the default group for a user on the Group Memberships page of the user account.

When you deactivate a user account, the user's name is removed from the lists of Task and Project assignees, Appointment attendees, and Approval routes. However, it still appears on the History tab of records where they have entered History records, and other areas where that user is referenced as the Created By, Modified By, and so on.

If you delete a user account, all references to the user are removed from all records. In the records, the Created By and Modified By fields point to the TeamConnectAdmin user account instead.

While a user is locked out of TeamConnect, only his or her ability to log in is disabled. The user account in TeamConnect remains active. This means that the user appears on all active lists, such as Appointment attendees, and can still be assigned to tasks or projects.

To unlock the user, clear the Account is Locked check box on the user account's General page. After doing this, the user is able to log into TeamConnect, and everything in his or her account is unaffected.

After you upload a plug-in, in order for it to be visible from the Plug-in drop-down list for first time use, you must refresh the list. To do this, click Load Plug-in. Afterwards, the Plug-in drop-down list will contain the name of the plug-in that you uploaded.

The additional record-level security restrictions of a custom object on its related objects does not include embedded objects.

In the Related Object Security block, you can set custom objects' record-level security to cascade to their related objects automatically. When read-only rights are cascaded from parent records to their related object records, users can still create related objects. For situations when parent projects have read-only access, due to security or workflow reasons, you can use the Other Restrictions block to deny users the ability to update, delete, or create related object records, even if they are the creators.

You must assign both Create record rights and View record rights for a group member to be able to create records. For example:

•From global record rights for end-users, you must assign both View all records and Create all records to a group. Afterward, group members will be able to create all record types described in Rights for End-users.

•For a specific record type (for example, contacts), you must assign both View Contact records and Create Contact records rights.

Users in the New Users collection are sorted alphabetically. If a collection contains many records you may not see the expected record near the top of the list. Users in the Recently Viewed collection are sorted with the topic record as the most recently viewed record.

After you create a custom object (project), you need to create a corresponding Involved. Afterward, from the User Rights list (of the group's Record Rights page), you can select the custom object and assign rights for the related Involved records.

Record locking only applies to system objects and custom objects for end users (see Rights for End-users). Record locking does not apply to user or group records.

If group members do not have rights to view any record types that belong under the Legal tab, then the Legal tab does not display. For example, Advice and Counsel, Cost Centers, Disputes, Time Entry Settings, and Transactions are record types that can display under the Legal tab so if a user belongs to groups that do not have rights to any of those record types, then the Legal tab does not display.

The actual expiration of a session might be significantly later than the session timeout warning. That's because of the application server's handling of expired sessions. For example, in BEA WebLogic, the default setting for checking for expired sessions is every 60 seconds. So if a session timed out, it would actually still be valid until WebLogic cleaned up the expired session, which might be up to 60 seconds from the timeout message. If you tried to log in again during this period, the still-valid session would cause a Recover Session page to appear. In this WebLogic example, if you wanted to alter the application server's behavior, you could consult WebLogic documentation for information about changing the applicable setting (invalidation-interval-secs).

This situation is also caused by application servers, as described in the question above. If you had the maximum number of concurrent users logged in simultaneously, and one user's session timed out, another user wouldn't be able to log in until the application server cleaned up the expired session.