dm_notes: Documentum Notes

October 5, 2007

What does Documentum recommend about deleting users?

Filed under: support note — Tags: , — Raj V @ 11:53 am

Note: Every SysObject or SysObject subtype in the Docbase has an attribute called owner_name that identifies the user who owns the object. We suggest deactivating users, rather than deleting them based on the following issues:

– Before deleting a user from a Docbase, you must update the objects created by the deleted user to change the owner_name to identify a different user. You do not need to change the owner_name if you deactivate the user.

– When you delete a user, the server does not remove the user’s name from objects in the Docbase such as groups and ACLs. It is possible to delete a user, and then re-create the user with the same name. However, if you add a new user with the same name as a previously deleted Docbase user, the new user will inherit the group membership and object permissions of the previously deleted user.

– You cannot delete the Docbase owner, installation owner, or yourself.

– When you no longer need a user account, deactivate the user. Deactivating a user is better than deleting a user. Once a user is deactivated in a Docbase, that user will not be able to log in to that Docbase. You must have Sysadmin or Superuser privileges to deactivate or reactivate a user.

– You cannot change the login state of the Docbase owner, installation owner, or yourself. You deactivate and reactivate users by changing the user’s login state using Documentum Administrator, DQL or the API.

– By default, users are active when you create them, so you do not need to activate new users. The user’s login state is tracked by the user_state attribute of the dm_user object. If you deactivate a user who is currently logged in, the change takes affect when the user next logs in.

– If necessary, a user with Superuser privileges can use a ticket to log in as a deactivated user, and a user with Superuser privileges can add a deactivated user to a group

NOTE: You can rename users to another existing user if necessary; this then deletes the original user. In our application it is our standard that every object should have someone who it belongs to, using renaming instead of deactivating accounts accommodates this requirement.

The users are created and authenticated at the OS level.

This is the way I intend to do this is by making all the object owners a user e.g. “system” and then we would delete the users that are not required from the Documentum system. This way all object owners would be “system” and whether or not the user is deleted from Documentum would not impact the system.

Note: This is a support note I found floating in yahoo groups. I am not sure of the support note no.  The EMC copyrights apply to this Note as it is authored by EMC.

Advertisements

Leave a Comment »

No comments yet.

RSS feed for comments on this post. TrackBack URI

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Blog at WordPress.com.

%d bloggers like this: