Deleting old User Profiles January 10, 2012
Posted by Tipster in Administration, PeopleSoft, Security.1 comment so far
Vanilla databases often contain 150-200 ‘example’ user profiles. While these can be useful to clone as a starting point early in an implementation, they’re frequently left dormant as the project continues – and sometimes still exist in Production post go-live.
It’s a straightforward task to lock the accounts, but once you have your security setup in place and your own template user profiles to clone then these ‘example’ accounts no longer serve any purpose. Here’s an easy way to delete them. (more…)
Creating an entirely read-only user in PeopleSoft August 28, 2008
Posted by Tipster in Oracle, PeopleSoft, PeopleTools, Security, SQL.comments closed
On big projects it is quite likely that large numbers of developers have access to a many environments. Occasionally they can have access to environment which is quite important, for instance one that the customer is using for training or testing.
To reduce the likelihood of developers accidentally deleting some data that they shouldn’t it would be quite normal to remove their access to the environment altogether. However if they need access for troubleshooting purposes then (at least on projects I’ve seen) it’s quite normal for developers to be told “OK, you can have access, but be careful not to do anything destructive”. Occasionally – as with everything – things can go wrong. Either someone forgets which environment they’re in, or does something with unintended consequences. An alternative to the “just be careful” approach would be to create an entirely read-only user profile (i.e. one that has display only privileges to every component system-wide).
A read-only user profile is shown in screenshot below, where no fields are editable and the save button is inactivated:
Also, on Run Control pages the ‘Run’ button is inactive. It’s going to be pretty difficult to alter data in this environment.
Here’s how to do it quickly and easily …
