This presentation is part of the Portals Overview Self-Study Course.

Transcript

Maintaining Too Many Portals

• The Portal rule a user sees is driven by his or her access group.  This does not mean there must be a one-to-one relationship of portal rules to access groups.  Your goal should be to reduce maintenance as much as possible.
• Do not necessarily create a new portal rule to handle exceptions.  For example if a small group of manager’s requires an additional unique report in a gadget, consider adding the report to an existing gadget and applying Rule-Obj-When rules to display the report given a specific privilege, access role, or org unit.
• Always parameterize your gadgets as much as possible to enable their use from all Portal rules by users in all access groups.

Renaming Out of the Box Portal Tabs

• Given the extensive JavaScript that has been written to support the application, it is recommended you do not change the name fields of tabs since many functions rely on these specific values.  You can change how they are displayed by changing the values in the Title column.

Using JavaScript Object IDs Multiple Times 

• You may find that you need to copy a gadget and modify it to build similar functionality for a client.  It is important that you rename the object IDs in the gadgets and in your custom JavaScript functions, especially if you continue to use the original gadget.  This holds true even if your gadget is located in a different portal tab.
• Process Commander loads the portal as one large HTML stream and reuses the IDs in various areas of the portal, so if you do not rename the IDs, you may experience JavaScript errors or other navigational errors while interacting with the gadgets.

Collapsing the left navigation bar as a default

• Some clients may have users who desire the left navigation bar be collapsed as a default.  This requires significant changes to finalized html rules.

Adding Custom Toolbars

• This becomes problematic as you navigate between the various portal tabs.  While you could easily modify the Work tab by adding sections to the top of harnesses etc., other tabs such as Monitor Work are more difficult as report displays tend to fill the entire IFRAME and the custom toolbar could be overwritten.

Why You Wouldn’t Use PRPC Portals

• Portals are not always a required component of implementations.  The following scenarios may lead you to look for an alternative solution:
• BRE applications or "Headless" applications using flows and other standard rules but has no user interface at all.
• SOA applications where the user interface is decoupled from the processing logic.  
• Directed web access to work objects to users who normally do not log on to the application.  Users receive emails regarding a particular work object waiting on processing with a link that, when clicked, presents the user with the appropriate Harness of the Work Objects requiring processing.