Content Reference Component Security inheritence

The typical content reference that references a component will automatically pull its security based on security assigned to a permission list(s).  However, if you put that component in multiple places within the registry, PeopleSoft will role-up permissions to the folders, and all of sudden you have end-users with access to menu folders that typically only an administrator would be allowed to see.  To control this, you can set the content reference to “public”, and then at the folder level add the necessary security, so for an administrative content reference, the parent folder would only have the administrative roles/permissions, and the content reference would be public.  This way the end-user can’t see the content reference in the administrative menu because they don’t have access to the parent folder level.

Multiple Portal Registry Entries Same Component

PeopleSoft created the Portal Registry based on same old fundamental designs that has some limitations to them.  One of those limitations is using the same component to do different functions.  There are times where a component could be used for multiple operations for example: Self Service. But the administrative functions could use it as well.  The option is to create your content reference the same way as always, but in the parameters add something like “attr1=admin”.  This will pass in a parameter to the content reference, so when you go to that new content reference, you can reference in the peoplecode using the call:  %Request.GetParameter(“attr1”); This will return the variable “admin” and you can do the necessary page operations for the administrative function.  Subsequently you can do the same thing again for the self service page where the parameter is: “attr1=selfservce”.  You can create an unlimited number of content references as long as they have a unique set of parameters.