Delete user account without losing information

Hi everyone,
this is with TS 6.7.2 on Solaris 10.

For legal reasons we need to be able to determine which user created/published a file for years to come, even if this user has already left the company.
Since we have more than 1000 active users, keeping the accounts of previous users intact will soon clog up the system (at least for the administrators/masters).
When you delete an account the name and user ID are lost and the files that were created/modified/owned by that user will only show a numeric value in the respective properties ("Modified By", "Owner", "Creator"). This goes for workareas as well as for the STAGING area and all editions a file might be contained in.

Does anyone know a way of getting rid of the user account without losing the information about file creation/modification/ownership in the TS store?
Is there some best practice regarding this issue?

Thanks for your input.

Find more posts tagged with

Comments

Reji Varghese

Oops - i didnt read that it was needed for Solaris

The number which you see is a system identifier (SID) which is assigned a windows domain controller.

Once you have the SID, you can associate it with a username using the following steps :
- Open Registry Editor and navigate to:
- HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion \ProfileList
- Under the ProfileList key, you will see the SIDs. By selecting each one individually, you can look at the value entry and see what user name is associated with that particular SID.

I am not sure, how long windows maintains these mappings.

Adam Stoller

Hi everyone,
this is with TS 6.7.2 on Solaris 10.

For legal reasons we need to be able to determine which user created/published a file for years to come, even if this user has already left the company.
Since we have more than 1000 active users, keeping the accounts of previous users intact will soon clog up the system (at least for the administrators/masters).
When you delete an account the name and user ID are lost and the files that were created/modified/owned by that user will only show a numeric value in the respective properties ("Modified By", "Owner", "Creator"). This goes for workareas as well as for the STAGING area and all editions a file might be contained in.

Does anyone know a way of getting rid of the user account without losing the information about file creation/modification/ownership in the TS store?
Is there some best practice regarding this issue?

Thanks for your input.

You could consider adding a step to your workflow processes that sets an EA on the file with a text string representing the user's id - or perhaps better, their full name. Since it's a text string and not a direct UID mapping - it will remain long after the account has been removed from the system.

tobias

You could consider adding a step to your workflow processes that sets an EA on the file with a text string representing the user's id - or perhaps better, their full name. Since it's a text string and not a direct UID mapping - it will remain long after the account has been removed from the system.

In this case, however, only the last version of the file would be tagged with this EA, not the version in the STAGING area, let alone the versions stored in editions.
In order to propagate the EA to STAGING (and a new edition), the file would have to be submitted (and published), which unfortunately would tamper with the "modified by" and "last modified" information.

Hmm - still no feasible solution, I'm afraid. But thanks for your thoughts on this, ghoti.

Adam Stoller

In this case, however, only the last version of the file would be tagged with this EA, not the version in the STAGING area, let alone the versions stored in editions.
In order to propagate the EA to STAGING (and a new edition), the file would have to be submitted (and published), which unfortunately would tamper with the "modified by" and "last modified" information.

Hmm - still no feasible solution, I'm afraid. But thanks for your thoughts on this, ghoti.

I'm not talking about a solution for all that's happened before - I'm talking about a solution for all that happens from here onwards. If you start tagging the files now, then 5, 10, 50 years from now - those EAs (and their values) will still be accessible.

I don't believe there is anything you can do (in TeamSite) regarding the versions of files that already exist - other than dump a bunch of information into something like a CSV file or database - and try to resolve all unknown UIDs with someone in IT who might be able to lookup the information for you - and then just hold onto that file as a means of mapping specific versions of content to specific users. It's an imperfect solution to an unplanned for problem - I don't think you're going to find much better for dealing with what's already in the past.

Bjorn

In this case, however, only the last version of the file would be tagged with this EA, not the version in the STAGING area, let alone the versions stored in editions.
In order to propagate the EA to STAGING (and a new edition), the file would have to be submitted (and published), which unfortunately would tamper with the "modified by" and "last modified" information.

Yeah - any solution you have will have to be two parts: one that addresses the existing data that's in your published and anonymous editions and one that addresses the issue going forward. But since data in editions is read-only, you'd almost have to record the attributes you'd like elsewhere or they will be lost as the users are.

Adam's idea would work going forward and would be good if you want to keep things "in the family" and not use outside processes. But you could also consider adding a workflow task or something that records the data you want to a DB with the file's vpath as a unique identifier. You'd want to make sure the vpath is to the anonymous (versioned) edition and not to the staging area directly. You could even use datadeploy to move the data, which would warm the heart of your sales guy. Then, to handle the existing stuff, you could write a Java class (or as Adam would suggest, a Perl script) that traverses all your existing content in editions, etc. and records this data to the same DB.

Disadvantage is that you're duplicating data to some degree and adding more potential points for failure for something that in a perfect world should be contained exclusively in TeamSite. Advantage is that it's not a perfect world and the product doesn't do what you need it to even if it has a good reason why -- so this lets you have your cake and eat it too, even if you'd prefer a different kind of cake. You'd have all that "legal" data in a single location and it's in a format that's generally more accessible and popular than a TeamSite repository.

Not a lot of good "standardized" solutions for your dilemma.

Adam Stoller

Semi-hurmous nit

... -- so this lets you have your cake and eat it too, ...

The correct phrasing (though often ignored) is "to eat your cake and have it too".

If you have cake, it's easy to eat it.
If you eat cake, you generally don't have it any more - thus making it much more difficult ;-)