OracleAS Portal Developer Kit (PDK)
Portal Tools Release Notes

System Requirements

The following are the recommended and minimum requirements to use and install the Portal Tools version 9.0.4.0.2.

Note:  You may encounter JavaScript errors when using a browser older than what is listed above.

What's New

Locale Personalization Level

The PDK-Java now provides more control over how much information from the portal session language is used when writing/reading default portlet customization data. Prior to release 9.0.4.0.2, all such available information was used when writing/reading default values (for anything other than the portlet's default locale). For example, if a portlet's defaults were edited by a user in locale "en-US" and by a user in "en-GB", those default customizations would always be stored separately. Using a new setting, the locale personalization level, the PDK-Java can now be instructed to write/read this type of customization with only the language code, with both the language and country code, or not at all. For more information, please see the PDK-Java V2 Release Notes

With this release of Portal Tools, the OmniPortlet and Simple Parameter Form portlets are pre-configured to use only the language code for customization with the default language of English ("en").

A complete list of new features is available within the PDK New Features article. 

Known Issues

• Bug#3024053 CHANGE REPOSITORY SETTINGS PERSISTS OLD CLIPPING DEFINITIONS 

  • Changes to the Security Repository settings may not reflect the change immediately.

  • Workaround: Every time you modify the Security Repository settings, you should bounce the OC4J instance to apply your changes. After you bounce the OC4J instance, go to the OmniPortlet Provider Configuration page (host:port/portalTools/omniPortlet/providers/omniPortlet). On this page, the Security Repository Configuration status will say "Not Configured." Click Edit, then click OK to apply the new settings.

• Bug#3015565 USER SPECIFIED CONNECTION INFORMATION IS NOT PERSISTENT. 

  • If a user configures OmniPortlet using repository A, adds named connections and later changes the repository to connect to connection B, any subsequent changes to repository A will hide existing named connections. The issue occurs because every time the repository is changed, a new vault ID is generated.

  • Workaround: Go to the OmniPortlet provider directory, which is the same directory where provider.xml of OmniPortlet exists. In this directory, view the file: vaultIdMappings.properties. This file contains all the vaultID mappings. The format is: username||||SID||||host||||port=vaultId. To retrieve existing named connections, note the appropriate vaultID, and insert it into the <vaultId> tag in OmniPortlets provider.xml file.

• Bug#3024059 :CONNECTION INFORMATION PAGE THROWS ERROR AFTER CHANGING REPOSITORY TARGET 

  • Suppose you configure OmniPortlet using a repository (A), then configure a secured data source to use Repository A. If you change this secured repository to connect to Repository B, the portlets using Repository A will display an error message saying "No Connection Information found." If you try to click Edit Defaults to change the connection information on the Edit Connection page, another error message displays that says "Failed to update repository." 

  • Workaround: Drop the portlet from the page and re-create it. 

• Bug#2938729 FILTER TAB DOES NOT HANDLE COLUMNS WITH SAME NAME FROM 2 TABLES 

  • Every data source should provide unique names for each column. For example, the SQL statement "select * from emp, dept where emp.deptno = dept.deptno" gives two deptno columns. In this case, OmniPortlet cannot distinguish the between two columns of the same name, and will only pick up the first column.

  • Workaround: Ensure that the data source does not contain duplicate column names.

• Bug#3007147 ERROR WHEN COLUMN NAME SAME AS PARAMETER OR FIELD NAME 

  • OmniPortlet cannot distinguish column, parameter, or field of the same name, and could generate unexpected results.

  • Workaround: Avoid using the column name as a parameter or field name.  Similar to Bug#2938729 (see above).

• Bug#2485361 PARAMETER/COLUMN ## REFERENCE IN DATA URLS ARE CASE-SENSITIVE

  • Names in OmniPortlet are case-sensitive.

  • Workaround: When using ## lexical reference in, for example, a hyperlink, make sure you type column name using the appropriate case. This follows the Oracle Portal model of case-sensitive parameters.

• Bug#2991543 SCROLLING LAYOUT DOES NOT WORK WITH NETSCAPE 4.79 

  • News Layout Scroll type is supported on IE and Netscape 7.0. It does not work with Netscape 4.79.

• Bug#2639560 CHART DOES NOT RENDER NUMERIC VALUES WITH COMMAS (100,000 20,000, ETC.)

  • Numeric value from a data source should not contain commas (e.g., 32,789). Otherwise, the value may be considered a text value when used in sorting, and thus will be skipped when the chart is generated.

  • Workaround: Remove commas from numerical values.

• Bug#2411864 DATASOURCE DRIVERS HIDE SSO CHALLENGE

  • The OmniPortlet provider exists and executes in a different tier to the Portal Application and does not have access to the Portal session information.

  • Workaround: Expose files uploaded to Portal as PUBLIC to enable OmniPortlet to access them.  

• Bug#2507823 CUSTOMIZE FREEZES YOUR EDIT DEFAULTS

  • The action of customizing a portlet creates a complete copy of the personalization object file.  Since all properties are duplicated, subsequently modifying the portlet through Edit Defaults will not be reflected in the customized version of the portlet. 

  • Workaround: To pick up the latest changes to the portlet the user must enter the Customize screen for the portlet and select Reset to Defaults. 

Installation

Follow the instructions within the Installing Portal Tools article.