How can we update all our user names in the cms database to employee ids without having an impact in the user’s BO profile (or account)?
It has been decided that in all our corporate systems including BO that we eliminate the use of user names like “jdoe” and replace it with corporate userids like “e10257”. Thus, in future Mr. John Doe will use “e10257” and not “jdoe” as user name to log into BO. However when he first logs in after the migration his account profile should be same and be able to view all the reports that were saved in the favorites and inbox.
We do not use single sign on or LDAP functionality and our log-in is purely handled by BO Enterprise.
Any recommendations or suggestions would be greatly appreciated.
You could do it in some SDK code - find the current user name, update it with the other. That should not break anything, BO should be looking at the account by SI_ID under the covers.
I’ve done some SDK code to change universe short names, it’s not horrible - SQL type code to get to the right record, SDK update / commit methods from there.
If you don’t have a ton of users, CMC and a good typist might not be horrible…
In XI the storage is no longer based on name - the folders should all be tied back to the user by the hidden IDs. I’ve renamed users that have left the company and been replaced by new folk (a lot, unfortunately) - they picked up all the documents of their counterparts. In 6.5 I would have had to go to the filesystem and do some renaming to finish up that process.
If you start messing with the SI_ID and SI_CUID (?), you’re in a heap of trouble, unless the repository is much smarter than I imagine.
I am not good with SDKs so i guess the manual approach is all I have left. But we have more 1000 users so its going to require some effort and without other viable option i guess i just have to type it in.
If you have support, it’s “free” to call BO and see if they have anything to share - you may get lucky. Also, browse the SDK forum here, see if you can find something similar - a lot of the code is very much like SQL. Get your record set, update the object, commit, and continue - you may find you can do SDK.
My $0.02… reports should never ever be tied to a user account. Instead, they should be tied to a department or a function. For example, reports for Inventory Management or reports for P&L. Employees coming and going should never affect the reports.
I agree with substring. People leave and join groups all the time. Associations with Functional Areas rather than individual people is more streamlined and recommended. Another example is: stuppose employee E has scheduled report R to run everyday. If that employee leaves the company and their BOBJ account is disabled, the report’s daily schedule will get interrupted and fail to run any longer.
(BOB member since 2002-08-19)
(BOB member since 2002-08-29)
(BOB member since 2004-01-16)
