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.

First of all, a warning. Before you delete anything make sure that you have adequate backups and have performed a trial restore recently.

For a little while now (at least from Tools 8.49) there has been functionality to delete inactive users. It classes an inactive user as one who hasn’t logged on for a set amount of days (using the LASTSIGNONDTTM field on PSOPRDEFN). You can check for user profiles that haven’t logged in for a long time (say, 2 years) using SQL like this:

select OPRID
     , LASTSIGNONDTTM
  from PSOPRDEFN 
 where LASTSIGNONDTTM <= sysdate-730

(note: sysdate-730 is approximately 2 years ago)

You’ll probably find that the list contains none of your users, but a lot of the ‘example’ accounts. These are the accounts that will be purged, so make sure that you’re happy that there are no important accounts in the list.

There are also a lot of example user profiles that have never signed in who therefore have a null LASTSIGNONDTTM. These need to be updated so that the process will also purge them:

update PSOPRDEFN 
   set LASTSIGNONDTTM = '01-JAN-01 00.00.00.000000000' 
 where LASTSIGNONDTTM is null

Once you’re happy with the purge list, we need to setup the process. Go to:

PeopleTools > Security > Password Configuration > Password Controls

Under the Purge User Profiles heading enter the amount of days that you’ve chosen (730 in my example) and click Save.

Then either click the Schedule button, or go to:

PeopleTools > Security > User Profiles > Purge Inactive User Profiles

Select a Run Control ID and run the Purge process. It’s not particularly fast (as it’s done via CI), but if you run the following piece of SQL you’ll be able to see your unneeded OPRIDs slowly disappearing:

select count(OPRID) 
  from PSOPRDEFN 
 where LASTSIGNONDTTM <= sysdate-730

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 …

1. Create User Profile

First, craft your perfect ‘read/write’ user profile. I’ll call this ‘DMD’. Now clone it using the ‘Copy User Profile’ functionality in the PIA. This creates a new user profile (in my case ‘DMD_R’) with the same Roles, and this is the one we’re going to turn read-only.

2. Create new Read-Only Permission Lists

First create the Permission Lists by cloning those that are currently against the User Profile:

INSERT INTO PSCLASSDEFN
(CLASSID, VERSION, CLASSDEFNDESC, TIMEOUTMINUTES, DEFAULTBPM,
STARTAPPSERVER, ALLOWPSWDEMAIL, LASTUPDDTTM, LASTUPDOPRID)
(SELECT CLASSID || '_R'
      , VERSION
      , CLASSDEFNDESC
      , TIMEOUTMINUTES
      , DEFAULTBPM
      , STARTAPPSERVER
      , ALLOWPSWDEMAIL
      , SYSDATE
      , 'DMD'
   FROM PSCLASSDEFN
  WHERE CLASSID IN (
      SELECT DISTINCT CLASSID
        FROM PSROLECLASS
       WHERE ROLENAME IN (
           SELECT ROLENAME
             FROM PSROLEUSER
            WHERE ROLEUSER = 'DMD_R')))

Don’t forget to add the sign-on times:

INSERT INTO PSAUTHSIGNON (CLASSID, DAYOFWEEK, STARTTIME, ENDTIME)
SELECT CLASSID || '_R'
     , DAYOFWEEK
     , STARTTIME
     , ENDTIME
  FROM PSAUTHSIGNON
 WHERE CLASSID IN (
     SELECT DISTINCT CLASSID
       FROM PSROLECLASS
      WHERE ROLENAME IN (
          SELECT ROLENAME
            FROM PSROLEUSER
           WHERE ROLEUSER = 'DMD_R'))

We add the pages to the new permission lists, but set Display Only to 1:

INSERT INTO PSAUTHITEM (CLASSID, MENUNAME, BARNAME, BARITEMNAME, PNLITEMNAME, DISPLAYONLY, AUTHORIZEDACTIONS)
(SELECT CLASSID || '_R'
      , MENUNAME
      , BARNAME
      , BARITEMNAME
      , PNLITEMNAME
      , 1 DISPLAYONLY
      , AUTHORIZEDACTIONS
   FROM PSAUTHITEM
  WHERE CLASSID IN (
      SELECT DISTINCT CLASSID
        FROM PSROLECLASS
       WHERE ROLENAME IN (
           SELECT ROLENAME
             FROM PSROLEUSER
            WHERE ROLEUSER = 'DMD_R')))

4. Create the new Read-Only Roles

INSERT INTO PSROLEDEFN
(ROLENAME, VERSION, ROLETYPE, DESCR, QRYNAME, ROLESTATUS, RECNAME, FIELDNAME, PC_EVENT_TYPE, QRYNAME_SEC, PC_FUNCTION_NAME, ROLE_PCODE_RULE_ON, ROLE_QUERY_RULE_ON, LDAP_RULE_ON, ALLOWNOTIFY, ALLOWLOOKUP, LASTUPDDTTM, LASTUPDOPRID, DESCRLONG)
(SELECT SUBSTR(ROLENAME, 1,28) || '_R'
      , VERSION
      , ROLETYPE
      , DESCR
      , QRYNAME
      , ROLESTATUS
      , RECNAME
      , FIELDNAME
      , PC_EVENT_TYPE
      , QRYNAME_SEC
      , PC_FUNCTION_NAME
      , ROLE_PCODE_RULE_ON
      , ROLE_QUERY_RULE_ON
      , LDAP_RULE_ON
      , ALLOWNOTIFY
      , ALLOWLOOKUP
      , SYSDATE
      , 'DMD'
      , DESCRLONG
   FROM PSROLEDEFN
  WHERE ROLENAME IN (
      SELECT DISTINCT ROLENAME
        FROM PSROLEUSER
       WHERE ROLEUSER = 'DMD_R'))

5. Add the read only permission lists to the read only roles

INSERT INTO PSROLECLASS(ROLENAME, CLASSID)
(SELECT SUBSTR(ROLENAME, 1,28) || '_R'
      , CLASSID || '_R'
   FROM PSROLECLASS
  WHERE ROLENAME IN (
      SELECT DISTINCT ROLENAME
        FROM PSROLEUSER
       WHERE ROLEUSER = 'DMD_R'))

6. Update the user profile with the new read only rolenames

UPDATE PSROLEUSER
   SET ROLENAME = SUBSTR(ROLENAME, 1,28) || '_R'
 WHERE ROLEUSER = 'DMD_R'

And that’s it, although you may well also need to perform the following:

• Run Portal Security Sync (to sync security up).
• Bounce the App Server and clear cache (my App Server didn’t pick up the signon times from the cloned permission lists until I did this).
• Run SJT_OPR_CLS (Refresh the Security Join Table that contains the Operator and Classid data)
• Close and reopen your Web Browser and clear it’s local cache.