Problems getting into edit mode

• Key: JS2-222
• Type: Bug
• Status: Closed
• Resolution: Fixed
• Priority: Major
• Assignee: Ate Douma
• Reporter: Jouni Rajala
• Affects Version/s: 2.0-dev/cvs
• Fix Version/s: 2.0-M3

Description

I am using JS2 from CVS/HEAD and checked it out couple of days ago.

Problem is that after logging in as administrator I can't get into edit mode of
portlets. Edit mode icon is missing from portlet entirely. After I once minimize
or maximize the portlet, edit mode icon appears and works normally.

On some pages it seems to work ok. Can't find any logic why it works
on some pages and why not on some others. I am using stock pages from
CVS and I haven't modified them in any way.

Comments

[Jouni Rajala]

Could somebody confirm that this problem exists ?

Confirmed.

This is caused by the caching of Decorator/Page actions security caching in the session by the JetspeedPowerTool.
After login (which doesn't result in a new session), the cached security information is still reused (for the pages you visited while not logged on).
Changing a portlet mode or window state flushes the cache for a specific portlet window and that's why you then see the edit mode you're entitled to.

There is another even bigger problem with this caching: the portlet url for the action is cached as well.
When *not* the SessionFullNavigationState component is used but the portlet parameters are always stored in the url, using the Decorator actions results in losing the current portlet parameters!

I'm half way a solution for this, together with the solution for JS2-194 (and JS2-231) and expect to commit these tomorrow.

[Ate Douma]

I'm going to commit a rewrite of the DecoratorAction creation and evaluation, together with a lighter implementation of the cached page and fragment action access security in the session.

All fragment action access security will be stored as bit flags in a HashMap contained in a new page based PageActionAccess component, replacing the current PortletWindowActionState component.
This new component handles all access evaluation itself and is stored in the session for each page.
It state also will be reset after a user logged on, effectively resolving this issues problem.

Note:
I will comment out using AccessController.checkPermission for fragment action access evaluation!
In the current implementation it is used but its result is inversed because right now it always returns false!
Once we have PorletPermission evaluation (for DecoratorActions at least) truly implemented/supported this can be enabled again easily, but right now its just a performance drain without any reason.

Furthermore, DecoratorActions (which contains a PortletURL for changing the current PortletMode or WindowState) now will no longer be cached as that could break the Portlet API requirement for maintaining current Render parameters (which occurs if not the SessionFullNavigationalState is used).

Finally, to support true browser caching of DecoratorAction image links, these now will be created off the PortalURL.getPageBasePath(): possible encoded NavigationalState within the current request url won't be part of the image url anymore.