My personal repository of PeopleSoft related findings. They cover various modules in CRM/HR/PeopleTools and whatever reusable useful information I can find to make my job easy.
this happens in both - HCM 9.1 and FSCM 9.1
both on peopletools 8.52.10
In PeopleSoft we have rows of data secured by adding special prompt views. This technique is widely used in almost all PeopleSoft product lines.
I have recently come across one interesting issue with it. Let me try to explain it.
Scenario 1:
I have a component A, with static search record. One of the fields in Search record is Business unit which is secured using prompt table, which is in turn controlled by OPRID.
For example, if user U1 has access to business units B1, B2,B3, he would see all the Business units on the search screen. If user U2 has access to business units B1 alone, he would see only that Business units on the search screen and not B2/ B3. seems logical, right? good.
This works great if you are visiting the page online through browser (4 tier mode).
Issue:
Created a new webservice and published from PeopleSoft on 8.51. Tested successfully using SOAPUI and worked fine.
Then tools were upgraded to 8.52 and the same service started failing with the above mentioned exception.
Try this solution:
1. Go to the Gateway Administration Page and then to the Advanced Options. 2. Change the ig.dtdLookup value from 'false' to 'true'. Save the changes. 3. Bounce the Web Server.
Two different ways to create pagelets in PeopleSoft:
Create a new pagelet using pagelet wizard
Complete the wizard with appropriate options, select the Pagelet folder and click Finish.
Navigation for pagelet folder: Under Pagelets
All the folders under this would be shown on the wizard options
Then go to PeopleTools> Portal > Portal utilities and then search for the pagelet added in the previous step and publish.
Next go to the Homepage tabs and select the appropriate Tab under which you would like to enable the new pagelet.
Go to Tab Content tab and then select the newly added pagelet under the appropriate pagelet folder
Create a new pagelet using a new content reference with Pagelet type under structure and content.
After creating a new content reference, enable it the way did it in the first method.
Once the pagelet created by using either of the methods, log in and customize the content for the pagelets to see only those pagelets you need.
I needed to generate the navigations for all the content references in peoplesoft as some of the users needed the ready reference. I had created some custom objects and then populated a custom table with all the necessary information.
Step 1:
Create a work record with a dummy field.
step 2:
On the fieldchange peoplecode of that work field add the following code.
step 3: import PTLT_SETUP:Utility;
&FindObjects = create PTLT_SETUP:Utility();
SQLEXEC("DELETE FROM PS_PSOFT_NAV");
&SQL = CreateSQL("SELECT PORTAL_NAME,PORTAL_URI_SEG1,PORTAL_URI_SEG2,PORTAL_URI_SEG3 FROM PSPRSMDEFN WHERE PORTAL_URI_SEG2<>'' and PORTAL_NAME=:1", %Portal, &PORTAL, &MENUNAME, &PNLGRPNAME, &MARKET);
While &SQL.fetch(&PORTAL, &MENUNAME, &PNLGRPNAME, &MARKET)
Definition security in application designer: (only for those objects which are maintained by PeopleTools of course e.g. PSWORKLIST table, WORKLIST page, etc.)
Important tables:
SELECT * FROM PSOBJGROUP SELECT * FROM PSOPROBJ
In application designer>Click on Go in the Top menu and then select Definition Security
Note: This works only with Primary permission list
When you create a group, always add those definitions to the left which you want to restrict and rest all on the Exclude side.
When you create a group with only Fields on the left side and rest all the definitions on the right side and then attach it to a primary permission list with displayonly =true, then all the fields (only those which are maintained by PeopleTools of course) would be seen by the developer but they won't be editable.
The way it works:
Scenario 1:
Suppose you want your developer to see all the Activity definitions but don't want him to change anything:
Create an object group just for all the Activity definitions - GRP_ACT_1 and save.
Open the permission list with the Primary permission list attached to his user profile, say HCPPITA in the definition security window
Add GRP_ACT_1 from right-side into the left-side window and from the top menu make it display-only.
Scenario 2:
Suppose you want your developer not to see any of the Activity definitions and for all other object definitions he should have full access:
Create an object group just for all the Activity definitions - GRP_ACT_2 and save.
Create an object group for all the definitions except the Activity definitions - GRP_ACT_3 and save.
Open the permission list with the Primary permission list attached to his user profile, say HCPPITA in the definition security window
Add GRP_ACT_3 from right-side into the left-side window and from the top menu remove display-only flag.
Let GRP_ACT_2 be on the right-side to exclude the access completely.
Scenario 3:
A functional user should not have any access, even read access to any of the peopletools objects.
Open the permission list with the Primary permission list attached to his user profile, say HCPPITA in the definition security window
Don't add any of the groups on the left-side window
--Accessible processes for a given user select * from PS_PRCSDEFNGRP WHERE PRCSGRP IN (select PRCSGRP from PSAUTHPRCS WHERE CLASSID IN (SELECT DISTINCT B.CLASSID FROM PSROLEUSER A, PSROLECLASS B WHERE A.ROLENAME=B.ROLENAME AND A.ROLEUSER='MSCCOMP_AV' ) )
--Accessible permission lists for a given user SELECT DISTINCT B.CLASSID FROM PSROLEUSER A, PSROLECLASS B WHERE A.ROLENAME=B.ROLENAME AND A.ROLEUSER='MSCCOMP_AV'
--Accessible process GROUPS for a given user select * from PSAUTHPRCS WHERE CLASSID IN (SELECT DISTINCT B.CLASSID FROM PSROLEUSER A, PSROLECLASS B WHERE A.ROLENAME=B.ROLENAME AND A.ROLEUSER='MSCCOMP_AV' )
Previously, I’ve presented a technique on how to effectively append javascript execution in your PeopleSoft pages. The technique could be used to append a stylesheet to a PS page; or run code to beautify the page, perhaps adding fancy functionality like drag-and-drop to the elements. Javascript execution using the technique, however, is static. It applies to those scenarios where you want the custom javascript to run at every page load. This how-to shows how to run javascript on your PeopleSoft pages conditionally. Here, PeopleCode sets the logic that determines when the javascript code will run. As noted in a previous post, this is not as simple as dropping a HTML Area on your page and setting the script in PeopleCode. This is because the value in the HTML Area field remains and the javascript code will keep executing at subsequent page refreshes. The solution though is not difficult, only a couple of additional simple steps are necessary.
The following steps assumes that you have derived/work field named DERIVED_JS.HTMLAREA which you will be using for this “PeopleCode-javascript pseudo integration”.
Create a HTML definition as your javascript template. Include all the necessary user-defined javascript functions that you need. (For the purpose of this how-to, let’s assume you save this HTML definition as USERJS)
At the scroll level 0 of your PS page, insert a HTML Area control. Assign this to the DERIVED_JS.HTMLAREA field. Again at scroll level 0 of your PS page, insert an editbox control. Assign this again to the DERIVED_JS.HTMLAREA field. Set the following page field properties: On the Use tab, check Invisible and Modifiable by JavaScript (in earlier versions of PeopleTools, this may be labeled as Modifiable from HTML) On the General tab, set Page Field Name to USERJSINJECTION. This is a critical step to prevent repeated execution of your user javascript. This control, in conjunction with the element added in the HTML definition, is a convenient mechanism to clear the value of DERIVED_JS.HTMLAREA on the next server-side execution (be it a prompt-table lookup, or PeopleCode execution like FieldChange or save processing). I will explain the Modifiable by JavaScript property in more detail in a future post. Now in PeopleCode, to execute your javascript function, all you have to do is populate DERIVED_JS.HTMLAREA with the HTML definitions contents: GetLevel0()(1).DERIVED_JS.HTMLAREA.Value = GetHTMLText(HTML.USERJS, "user_function1()"); The 2nd parameter of GetHTMLText() substitutes the value of %bind(:1). It effectively specifies which javascript function to execute. Make sure that the parenthesis (along with function arguments, if any) is always included. That’s all there is to it. Note that the javascript is actually executed immediately after the page refresh that occurs after PeopleCode executes. The related posts provides explanation of the addLoadEvent() javascript function.
Allowing the use of % - wildcard character in PS Query prompt ::
Make sure for the prompt definition the edit type is 'No Table edit' and Also while using this prompt in the Criteria definition, make sure the operator is 'Like' and not 'Equal to'
For Group by functionality in PS Query, whenever an expression is defined to have aggregate function in it, check the box which syas 'aggregate function'
The process group are not stored in any setup table of its own.
They are stored in the table: PRCSDEFNGRP and PRCSJOBGRP where we store the process and job definitions.
If you take a look a look at the prompt for PRCSGRP field in those tables, it is a 'Prompt with no edit', so u can keep adding new Process groups on the fly, on process and job definition components (Page: Process Definition Options)
Significance of the process group:
They are linked with the user ID through a permission list. On the permission list setup, in the "Process tab", you can link the process groups.
If process 'x' is in the process group 'y' and any of the permission lists for a given user does not have access to that process group then, that user cannot run the process 'x'.
This plays very important role in securing the processes and jobs in the system.
Log in to Peoplesoft using the log in screen or single signon
In the same brower window which is opened, type javascript:document.cookie and press enter.
You can see the cookie that is generated for that page.
8.48 tools onwards, the application messages, Channels are termed as service operation and Queues.
There is a requirement, that the user who is publishing the message has to be present on the subscription side. Passwords need not be same.
For e.g. HR and CRM have delivered PERSON_BASIC_SYNC service operation. When a user abc is creating a person in HR, for successful creation of person record in CRM, user abc should also be present in CRM.
All the fields in a given record created in application designer, including the fields in subrecords
This also stores all the record field properties like prompt tables, key, alternate keys,etc.
SELECT * FROM PSPNLFIELD
All the fields present on a page created in application designer. This also has page field properties, co-ordinates, etc.
SELECT * FROM PSAUTHBUSCOMP
Authorized component interfaces (CI) in a a given permission list with the authorized actions on a given CI.
SELECT * FROM PSAUTHWEBLIBVW WHERE CLASSID='ALLPAGES'
Authorized web libraries in a given permission list.
SELECT * FROM PSAUTHITEM_VW2 WHERE MENUNAME LIKE 'WEBLIB%'
All the properties related to web libraries with authorized actions through menu
SELECT * FROM PSAUTHWS In 8.48 tools onwards, this table stores the authorized webservices
To find out the details about the portal tables:When you are not sure about the navigation for some components this table will help you find the folder. This is a sure-shot back-end approach.
SELECT * FROM PSPRSMDEFN
This table will help you find out the access to portal registry content:
SELECT * FROM PSPRSMPERM
Finding the SQL text for a view:
SELECT SUBSTRING(SQLTEXT,1,10000) FROM PSSQLTEXTDEFN WHERE SQLID='XREF_PSRECDEFN'
