What was committed[1] today for a change was adding two options to the PortletPreferencesServiceImpl. -storeGuestPreferences specifies if portlet entity preferences should be stored for guest users at all, if false all store calls result in no action and no entity level preferences are loaded for the portlet, if true the preferences will be stored, how is depends on the next setting. This defaults to true. -shareGuestPreferences specifies if portlet entity preferences should be persisted for the corresponding IPortletEntity, if true the preferences are stored in the database and shared between all guest user sessions, if false the preferences are stored in the guest user's session and only last until the end of that session. This defaults to false.
'guest users' are qualified as any user where IPerson.isGuest() returns true.
-Eric [1] http://developer.ja-sig.org/source/changelog/jasigsvn/?cs=43515 Cris J Holdorph wrote:
I don't know that it does in all cases. I would make that functionality optional if it's coded. Some portlets, might implement functionality in their EDIT mode that doesn't necessarily have to do with the Portlet Preferences. Sure, in general that's what EDIT mode should be for, but there is no requirement for it to be that way.However, if as an Admin for a uPortal instance, I know all the portlets I put on my Guest view, have EDIT modes that don't make sense, for 'guests', then I think it's reasonable, to have a way to turn it off.---- Cris J H Jason Shao (CampusEAI Consortium) wrote:On Apr 9, 2008, at 3:17 PM, Eric Dalquist wrote:Jen realized today playing in the 3-RC3 quickstart that if a portlet allows guest users to change portlet preferences these are persisted for the guest user and shared between all guest users. We're pretty sure this same behavior exists in 2.X as well. Since we have a portlet with preferences on the guest layout in 3.0 we're going to work out a solution to the problem as follows.The PortletPreferencesServiceImpl will have some additional options available via bean properties; first to just not store portlet prefs for guest users, second to store them in the guest user's session so they are scoped and disappear at the end of their session, third to leave the functionality as is.If this sounds reasonable I'm also wondering how we define who a guest is. Should the code check IPerson.isGuest() or IPerson.getSecurityContext().isAuthenticated()?Am wondering if it also makes sense from a UI perspective to hide the edit button for portlets when rendered in the guest mode. Does the idea of customizing preferences even really make sense for guests, since there's no persistance?Jason -- Jason Shao Director of Open Source Solutions CampusEAI Consortium 1940 East 6th Street, 11th Floor Cleveland, OH 44114 Tel: 216.589.9626x249 Fax: 216.589.9639
smime.p7s
Description: S/MIME Cryptographic Signature
