We have raised a PMR with IBM (#72365,000,834). IBM has confirmed that the fix will be out in WebSphere Portal 8.5 CF12.

Users are unable to switch to projects that contain spaces in their name after they have access an anonymous page (without “myportal”). The behavior will persists until he/she has log out. Do take note that this behavior is only observed in WebSphere Portal CF 10.

Why would a user remove “myportal” from the url (in case L2 asking for use-case scenario again..)?
This is to simulate editors clicking on one of the relative links in the contents (for example a relative link (/contact-us) in “About Us” page that links to a “Contact Us” page).

An editor might click on “contact us” link to verify the link before switching to a project.

How to replicate:

• *IMPORTANT* Ensure you have follow the instruction in “Changing the site URL after an installation” article to remove the context root and you are using WebSphere Portal CF 10.
• Login to WebSphere Portal.
• Create a new project by clicking on the “New Project” link.
  
• Use the default project name which comes with a space. Click on “Create” button.
  
• Switch back to Published Site.
  
• Close the Project dialog.
  
• Remove “myportal” from the url and press Enter.
  
• Now switch to the project that you have created earlier.
  
• You will realize that it will remain as “Published Site” even if you tried to insert “myportal” back.
  

We have raised a PMR with IBM (#72308,000,834).

Our users highlight that the website “break” in IE whenever they click on the “Edit” mode button. The team examined and identified that this only happened to websites that are classified under Local Intranet Security settings (see screenshot below). This bug affects most of our intranet users as IE auto classified intranet websites under Local Intranet Security.

Current workaround: We advise them to exclude the site from Intranet Security settings or use alternative browsers like Chrome while we trying to get IBM to fix it.

In the example below, we will illustrate how to replicate the issue in your local environment using IE 11 and WebSphere Portal CF 9.

How to replicate:

• Ensure that you have the following:
  • WebSphere Portal CF 9 and above (though we suspect this issue starts from the problematic WebSphere Portal CF 8 after they fixed the Site Manager bug)
  • IE 10 and above
• Go to “Internet options” in your IE settings.
  
• Go to “Security” and click on the “Sites” button.
  
• Click on “Advanced” button.
  
• Key in the website hostname that you wish to include in Local Intranet Security and click on the “Add” button.
  
• Click “OK” button to close the “Local intranet” dialog.
  
• Click “OK” button to close the “Internet Options” dialog.
  
• Login to your website and toggle the “Edit” mode button.
  
• *Poof!* The theme breaks!

We have raised a PMR with IBM (#72284,000,834).

A better feedback message is needed to inform the user that he/she need to be in a project in order to create a page from a workflow page template in Manage Pages portlet.

How to replicate:

• Before proceed, ensure that you are using WebSphere Portal CF 9 and above and there is a workflow page template.
• Login to Portal Administration page (http://<hostname>/myportal/Administration).
• Go to Manage Pages (Portal User Interface > Manage Pages).
• Click on “New Page from…” button.
  
• Select the workflow page template *IMPORTANT* and click on the “OK” button.
  
• A “EJPAS0017E: Unable to create <page title>” will be displayed, leaving the user trying to figure where he/she went wrong.
  

We have raised a PMR with IBM (#72274,000,834).

There is an un-catch null pointer exception bug in WebSphere Portal if “wps.content.template.default” is the first child under Page Templates and it is inactive.

How to replicate:

• Before proceed, ensure that you are using WebSphere Portal CF 9 and above and there are at least 2 page templates.
• Ensure that “wps.content.template.default” is the first child under Page Templates is inactive and the node is set inactive.
• 

• Toggle “Edit” mode and proceed to create a child page.
  
• Key in the Page’s title and click on the “Create Page…” button. DO NOT SELECT any page template.
  
• A “java.lang.NullPointerException” error message will be displayed, leaving the user trying to figure where he/she went wrong.
  

9 Feb 2016: We have raised a PMR with IBM (#63843,000,834). 

9 March 2016 - IBM L2 replied:
"This seems to be an environmental issue. We tried to recreate the same on several local environments; but it's working absolutely fine everywhere! Will try on other environments; you may also meanwhile retry on other environments and update us." 

We immediately replied that we are able to replicate the issue in all of our environments (including local).
 
11 May 2016: IBM L2 finally acknowledge that they are able to replicate the issue after 3 month of "ding dong". #AmazingJourney #L3WillKnowImmediately #StopHogging


27 May 2016: IBM has come back with a fix (IFPI63085).

IBM finally allow us to remove context root using Configuration Wizard but it seems that the configuration wizard has missed out editing the context path in one of the javascript files (\PA_WCM_Authoring_UI.ear\ilwwcm-authoring.war\layers\full.js) in PA_WCM_Authoring_UI.  This in return causing a broken “error” icon with the comment dialog. The only reason why we keep pushing it as PMR (instead of fixing ourselves) is because we do not want to keep patching the file every time we patch the server with new CF.

How to replicate:

• Follow “Changing the site URL after an installation” article to remove the context root.
• Attach a content with a workflow that requires user’s comment on approval.
• Click on the “Ok” button without keying anything in the comment box and the error will appear.
  
• We can easily tell that the javascript is still referencing “/wps” by inspecting it using developer tools.
  

We have raised a PMR with IBM (#72198,000,834) and IBM has confirmed that it is working as designed since author has assigned anonymous access at Draft stage. Furthermore, below example shows that we are accessing the file directly through Connect servlet instead of rendering through Web Content Viewer portlet (or Menu Component).

To sum up IBM reply:
1) Render through Web Content Viewer Portlet/Menu Component = Draft Content/Component will not be accessible by anonymous users (despite access rights have been granted to them)
2) Render through Connect Servlet = Anonymous users are able to access (because access rights are granted to them)

Our Take:
As developers, we understand IBM rationale. But we felt that in an ideal situation (and to make things easier for users to understand), anonymous users shouldn't be able to access a DRAFT content/component even if access rights are granted to them (regardless if they are hitting Connect servlet directly). 

UX teaches us that we shouldn't rely on the users to do the "right" things by linking it through rich-text editor. Definitely there will be lazy users who would copy the file link and link it up as content.

Conclusion: Tighten up Connect servlet security by preventing anonymous users able to access Draft content/component directly (regardless if access rights are given to them).

IBM allows administrators to enforce workflow for Library’s resources by adding “com.<resource type>=com.aptrix.pluto.workflow.WorkflowControl” in WCM WCMConfigServices custom properties. But the team has discovered that anonymous users are able to access the file in the file component despite the fact that the component is in Draft stage.

IMPORTANT, before you proceed, please ensure that your library is properly configured:

• Login to Portal Administration page (http://<hostname>/myportal/Administration).
• Go to Portal Content > Web Content Libraries.
  
• Click on “Set Permission” icon for the library where you going to save your component in.
  
• Ensure that “Allow Propagation” and “Allow Inheritance” are checked and click on “Edit Role” icon.
  
• Ensure that “Anonymous Portal User” is added in the library’s User Role.
  

How to replicate the issue:

• Go to Web Content Authoring Portlet (http://<hostname>/myportal/Applications/Content/Authoring).
• Add a new file component (New > Component > File).
  
• Key in the component’s Name, Display Title and upload a random file.
  
• Click on “Add Workflow” button if you didn’t enforce the workflow in WAS.
  
• Click on “Properties” tab and  add a workflow.
  
• Click on the “Save” button to save the changes.
  
• At this moment, your file component is in Draft status.
  

• Click on the “Properties” tab again and ensure that “[anonymous portal user]” is been inherited in the Access section.
  
• Copy the file’s url in the File Component.
  
• Paste the url in a new browser (or in private / incognito mode) and remember to remove “my” from “myconnect” as using “myconnect” would prompt you to log in.
  
• Press enter and you are able to download the file despite the file component is in Draft mode.
  

We have raised a PMR with IBM and they have provided us with a temporary workaround for CF9 and below (as of 18 Mar 2016). The full workaround should be in WebSphere Portal 8.5 CF10.

9 May 2016: We have confirmed that the bug has been resolved in WebSphere Portal 8.5 CF 10.

How to replicate the issue:

• Ensure that your WebSphere Portal version is 8.5 CF9 and below
• Ensure that your Chrome browser is up to date
• Open any content that is long enough for the Chrome vertical scrollbar to appear in Inline Editing.
  
• Click on any button and the Chrome scrollbar will disappear.
  

Below is IBM temporary workaround (as of 18 Mar 2016).

For WebSphere Portal 8.5 CF9 and below, modify the following files:

• AuthoringUIView.jsp (<wp_profile>/installedApps/cellname/PA_WCM_Authoring_UI .ear/ilwwcm-authoring.war/jsp/html/AuthoringUIView.jsp)
• dialogCloserLaunchPage.jsp ( <wp_profile>/installedApps/cellname/PA_WCM_Authoring_UI .ear/ilwwcm-authoring.war/jsp/html/dialogCloserLaunchPage.jsp)

with the following codes:

/*BEFORE: find the following lines */
dojo.addOnUnload(function() { 
 if (frameElement) { 
  frameElement.scrolling="no"; 
 } 
});

/*AFTER: change the code as follows */
dojo.addOnUnload(function() { 
 if (frameElement) { 
  if (i$.isChrome) { 
   frameElement.scrolling="auto"; 
  } else { 
   frameElement.scrolling="no"; 
  } 
 } 
}); 

There is an additional step for WebSphere Portal 8.5 CF8 and below:

• Go to <PortalServer>/theme/wp.theme .modules/webapp/installedApps/ThemeModules.ear/ThemeModules .war/modules/dialog/js/.
• Backup dialog_layer.js and dialog_layer.js.uncompressed.js.
• Copy dialog_layer.js.uncompressed.js content to dialog_layer.js and modify the file with the following codes:

/*BEFORE: find the following lines */
// Don't display scrollbars until dialog content has loaded, this is set back to auto in onLoadFrame 
// Note: in chrome setting overflow style to hidden will not hide scrollbars 
f.setAttribute("scrolling","no");

/*AFTER: change the code as follows */
// Don't display scrollbars until dialog content has loaded, this is set back to auto in onLoadFrame 
// Note: in chrome setting overflow style to hidden will not hide scrollbars
if(i$.isChrome) { 
 f.setAttribute("scrolling","auto"); 
} else { 
 f.setAttribute("scrolling","no"); 
}