What all would be the implications of wanting to give someone an old userid in security? Say you had a previous employee, Sam Johnson, with the userid sjohnson who worked with your company for a few years. That person left a couple of years ago and now a new employee, Sarah Johnson, wants to have the same userid. Is there not some sort of conflict there (userid being the primary key in T_METUSER) with regards to historical data, audit trails, and so forth? It seems to me it would be ill-advised to try to make the appropriate changes manually on the back end.Am I right? Just wanting to make sure I know what I'm talking about.
Thanks, Tessiturians.
Sounds like your ideas on the matter are consistent with mine. UserIDs are strewn about everywhere, and despite being the primary key for T_METUSER I wouldn't trust a foreign key-dependency search to tell me all of the locations it is used. So, doing a mass update of an old ID would not be a good time.
The caveats to reusing an old userid, as far as I'm concerned, would be: any lists owned by the old user would become editable by the new one, and: your audit columns no longer let you use the single dimension of userID to separate person from person--now you also have to include datetime to figure out who did what change. Any report data run by the old user should have long been expired, and there really isn't any private user-specific data in Tessitura that I can think of. But for me, the extra dimension required for person-level auditing (and that there's nowhere in the existing schema to store that information) is enough to make me avoid it and just require the use of a new username.
I would agree with Nick's thoughts on this as well. Trying to mass update the old ID to something else would be near reckless.
And regarding historical data, it might also be relative to the specific department/tasks the previous/new employee did/will be doing. I know things like Financial audits can get pretty deep in, and if they do not have an accurate line delineating which of those two was which, I think that could potentially get sticky, too. If you got into a situation where they really needed to tear apart the history, and either or both of these employees were heavily invovled in the financial aspects of your organization... Now, as you say, there is theoretically the date range which tells these two apart, but say the new employee has to make slight changes to old data to conform to new standards for reporting, etc... Not all of the tables have audit trails, so things COULD potentially become confused there.
I suppose I would also lean towards using a new userid for the new employee. But these are just my thoughts.
John