pablocp/liferay-portal — pull request #17 by marcellustavares (2014-09-19 14:20:33+00:00)
Title: LPS-47412 DDL record search results will navigate to a null page and display that the resource is not found

https://issues.liferay.com/browse/LPS-47412

Hi Marcellus,

Sorry for the delay. It took more time to finish than I thought before. During the fix, I was struggling with the following problems:
1- DDLRAssetRendererFactory is set to non-selectable
2- Asset entries are created as non-visible, therefore, they cannot be displayed (right now) in AP
3- OpenSearch results are already working for DDLRecords, because DDLIndexer#doGetSummary uses DDL Display portlet. (See the description of the LPS for more information about this.)

4- We have a quite weird logic to create "full" and "viewInContext" URLs for the results in main_search_result_form.jsp

First, I wanted to add a new condition to check the assetRendererFactory:
````java
if (assetRendererFactory != null && assetRendererFactory.isVisible()) {
````

in order to use the specific portlet ("portletId" <-- Document) to create the URL and then, retrieve the final URL from the Summary -->

````java
if (summary != null) {
if (assetRendererFactory == null || !assetRendererFactory.isVisible()) {
viewFullContentURL = summary.getPortletURL();

viewURL = viewFullContentURL.toString();
}
````

Though, it turned out that
a.) this would break the links for the Users, as UserIndexer#doGetSummary creates URLs for the "Users & Admin" (125) portlet, which one cannot be instantiated automatically on all page (by default), only within Control Panel scope, so right now you may get "You don't have the required permission to access this portlet". message if you use the PortletURL from a User Summary and you are not an Control Panel page.
b.) UserAssetRenderer#getURLViewInContext provides correct URLs, as it uses the "getDisplayURL" on the given User object, that returns links to the user's public page (if exists).
c.) UserIndexer#doGetSummary doesn't have the whole User object, so it cannot do the same as the AR in b)

Finally, I chose this way which
- doesn't prevent the usage of AR if one is available
- assumes that the AR provides valid/working URL so it navigates the user the right portlet to display.

Sorry for the long comment, but I wanted some more insights.

Regards,
Tibor