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