Creating an entirely read-only user in PeopleSoft

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 …

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'))

3. Make the Permission Lists Display Only

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.

Like this:

Like

Be the first to like this post.

Comments»

1. Brad B -August 29, 2008

Hyperlinks on pages where you need to drill down sometimes are inactive in view only depending on the setting in app designer. I find this on pages where the concept of the page was to view details only and not do data entry. How do you handle this? I have found that we need to go in and remove the view only access for these pages.

Reply

2. Ramesh -September 11, 2008

I think there is a page field property called Enable When Display Only or something similar that you could trun on to resolve this. But, this goes as a customization

Reply

3. Tipster -September 19, 2008

You’re right. Unfortunately I’m not sure there is a way to resolve this without customisation.

Reply

4.Brent Martin -September 30, 2008

Usually there’s no need to set the DISPLAYONLY flag to 1 if the menu barname is like INQ% or REPORT% or RPT%. Running a quick update statement to set DISPLAYONLY back to 0 for those rows in PSAUTHITEM will get you close.

Reply