Certain limitations and restrictions apply when designing preload notices.
Because preload notice JSPs are shown as part of the XDIME aggregator, any custom policies must be imported into the aggregator policies project. You may use any of the existing policies, but see the topic Importing aggregator policies for more information about how to import your own custom policies.
Because preload notice fragment JSPs are included in the MPATheme EAR, you must update and redeploy the EAR if you add or modify a fragment JSP. See the topic Deploying updates to the MPATheme EAR in this information center.
For performance reasons, the user preload notice history information is read from the database and cached in the user session. This reduces the number of database accesses when this information is needed to determine whether preload notices should be displayed. However, depending on your setup, there are known issues as to when the session information is persisted back into the database. If the user does not explicitly log out of WebSphere® Portal, the session remains active. This poses a problem if your portal site contains pages that can be accessed from both privileged (authenticated) and unprivileged (anonymous) users. If the user roams within privileged pages, then the session is reused. If the user roams out to unprivileged pages and happens to log back in, then a new session is created containing previous preload notice history information leaving the old session idle. The idle session will remain until a timeout has occurred in which case the preload information is finally persisted into the database. Because of this behavior, if you are configuring any preload notice rules, it is recommended that all pages are tagged as privileged only.
Preload notices have an option to allow users to check a check box to indicate that they do not want to be prompted by the preload notice again. This function behaves correctly only if one of the buttons that are with the check box is selected. If any other action is taken, such as selecting a link or exiting the browser, then the check box will not be registered. These buttons are specially configured to send a request to the WebSphere Portal server to remember the check box option and to direct the user to a target URL.
You may be limited by the device when designing a custom preload notice JSP fragment. A device may have memory constraints which will prevent you from developing rich content. This includes the number of buttons that you are allowed to add to the JSP fragment. Ensure that you test the preload notice on the actual devices to verify that the generated markup does not exceed any device limitations.
A customer can easily bypass receiving a preload notice. For that reason, preload notices should not be used for access control to content. The buttons on a preload notice are not necessarily used by the end user if they find a way to bypass the preload notice.