End users don't always like the usability of PeopleSoft, but what about the people that have to administer PeopleSoft? In a previous entry I wrote about some ways of fixing up the usability of existing PeopleSoft pages for end users, but this time around we'll look at a way to make life easier for the system administrators.

Someone that I met at the recent Financial Services Industry User Group meeting brought up an issue that they were having with the PeopleSoft portal registry. Someone had run the menu import process (which populates the portal registry for PeopleSoft components that are not already in the registry) by accident. This caused them to end up with some extra portal references that they didn't want.

Since there isn't an "undo" feature for the menu import (and unfortunately it doesn't even log what actions it takes), the quick thing to do is when you see a link online in the portal that you don't want, go to where that link is registered and either change the security on it, or change the dates that the link is active, or flag it as hidden.

The normal steps for doing this is to select the PeopleTools folder from the portal navigation, and the Portal subfolder, and then the Structure and Content link (this requires that you have the Portal Administrator role). This gets you into a page that shows the entire structure of the portal registry and allows you to manage links and folders in the portal. Then you get to click through the folder structure to find the link or folder that you're looking to edit.

Sounds like a lot of clicks, eh? It is, which is why the portal registration wizard was added to Application Designer to make it easier get a new component registered into the portal. When the first builds of PeopleTools 8.4 were rolling internally, the PeopleSoft application developers were screaming about how much work it was to work with the portal registry. But the portal registration wizard doesn't help us in the scenario that we're working with.

It would be nice if we could drill from any online page directly into the portal registry administration page for that page. In order to make that happen, we'll first setup an iScript that can take the current URL and use that to figure out what URL to use for the portal registry administration. Then we'll setup a bookmarklet in our browser that will grab the URL of current page and send it into the iScript.

Let's start by taking a look at the iScript.



We start with a couple of helper functions. One for looking up the portal content reference by passing in the name of the menu/component/market that is being looked for. The other function takes a URL string and uses that to look up the portal content reference.

Then we get into the actual iScript itself, the function iScript_DrillToCref. It looks for a "crefurl" parameter (this is what our bookmarklet will pass in). If it finds that, then it looks to see if the current URL is a portal folder or an actual content page. Then it looks up the content reference in the portal registry (to make sure that it exists, etc.). If so, then it redirects to the appropriate page for maintaining the current URL in the portal registry.

In order to get the current URL into the iScript, we'll use a bookmarklet to generate the appropriate reference. For those that don't know about bookmarklets, they are like regular bookmarks, except that they use javascript instead of a plain URL. The javascript can do things like look at the current URL in the browser (which we need) as well as setting the URL to navigate to. Bookmarklets can do a lot more than that though. To learn more about bookmarklets and find some really cool pre-developed bookmarklets, check out bookmarklets.com or Jesse Ruderman's bookmarklet pages.

The one drawback to bookmarklets is that the entire javascript function has to be on one line. Our javascript logic looks something like

var g = 'WEBLIB_GS_CREF.VIEW_CREF.FieldFormula.iScript_DrillToCref';
var u = '../s/' + g + '?crefurl=' + escape(location);
location = u;

Fairly straightforward, but the actual bookmarklet has all of that on one line, plus some extra code that is needed to function as a bookmarklet. It's easiest for getting going with the bookmarklet to just drag the following link to your Bookmarks/Favorites bar.


You may get prompted about whether you really want to do this (some browsers give this security warning), but just go ahead and click OK. Note that clicking the link here won't work it only does anything useful when are logged into a PeopleSoft portal page and you select that link from within your browser favorites.

Of course, the bookmarklet won't do you any good if you don't have the iScript installed. I've uploaded a PeopleTools project with the iScript in it. You just need to register the iScript function itself using the portal registration wizard in Application Designer. You should grant access to the Portal Administrator role (permission list PTPT1300) for this iScript. That's the same role as has access to administer the portal registry.

There's some more functionality to this, but it's late and I'm tired so you'll have to look at the code :-)

What I've explained so far will save you anywhere from 5 to 10 clicks each time that you want to look at the portal registry information for the current PeopleSoft page that you're on. That adds up over time.

Happy administrating!

Labels: PeopleSoft