Thanks for all the feedback. I've committed a change to the trunk that introduces three new lifecycle-specific subscribe permissions. Developers and fragment owners should now be able to subscribe to and render channels in all lifeycle states, while other users will only see published, non-expired channels.
I've decided to hold off for now on separating subscribe and publish permissions. Until we introduce an improved permissions user interface, it seems like the split permissions might simply be too hard to actually use. Anyone who's interested is welcome to try out the new changes in trunk. I'd recommend performing an initdb to pick up all the new permissions. Thanks again, - Jen On Tue, Nov 10, 2009 at 10:57 AM, Susan Bramhall <[email protected]>wrote: > Got it. So the change is still useful but will be painful to take > advantage of until the new flow is developed. Still +1. > Susan > > > Jen Bourey wrote: > > Unfortunately we can't do this until we write a new webflow for editing > permissions. I don't think we want to try to call the IChannel-based grous > servant from the new portlet. Of course, once we have that flow it becomes > easy to re-write the permissions channel and to create groups and channel > specific subflows. > > - Jen > > > On Tue, Nov 10, 2009 at 10:29 AM, Susan Bramhall > <[email protected]>wrote: > >> I agree that changing that UI is a big deal. Would it be possible to >> provide limited options through the portlet admin interface to set these new >> permissions rather than have to go into the permission manager to set them? >> Maybe not since it would have to use the ancient groups servant to do it? >> I'm not sure, just asking. >> Susan >> >> Jen Bourey wrote: >> >> I agree that having a new permissions UI would be extremely helpful. >> Eventually the goal is to rework the groups and permissions interfaces as >> new Spring Webflows, like we've done with the portlet administration >> pieces. I believe that work is covered by the description of ticket >> UP-2047, so as the portlet administration portlet work draws to a close we >> might next look at rewriting the groups and permissions portlets. I think >> it's unlikely that those re-writes will be completed by the upcoming 3.2 >> release. >> >> - Jen >> >> >> On Mon, Nov 9, 2009 at 6:47 AM, Bramhall, Susan >> <[email protected]>wrote: >> >>> Forgot to mention one other concern. The permission manager UI is one of >>> the scariest I've come across - at least in uPortal. I am hoping we would >>> administer the new permissions via the portlet administration portlet not >>> the dreaded permission manager. >>> Susan >>> ________________________________________ >>> From: [email protected] [ >>> [email protected]] On Behalf Of Bramhall, Susan [ >>> [email protected]] >>> Sent: Monday, November 09, 2009 6:45 AM >>> To: [email protected] >>> Subject: RE: [uportal-dev] Render/subscribe permissions proposal >>> (UP-2499) >>> >>> Jen, >>> Thanks for this really nice write up on the subscribe behavior as it >>> relates to channel caltegories. Could you clarify the mystery top level >>> behavior for me? We take advantage of the fact that a channel with NO >>> category can be pushed to a user in a fragment but the user cannot subscribe >>> to the channel themselves because the subscribe mechanism does not include >>> channels with no category. These channels also cannot be adminstered >>> through the portal UI. >>> >>> I am not familiar with the behavior you describe for channels in the "All >>> Categories" group. Is this the behavior you are talking about? When a >>> channel exists in NO category is it really in the "All Categories" Category? >>> If this is the case I agree that your proposed change to have an explicit >>> permission to render but not subscribe fits the bill perfectly. >>> >>> Susan >>> ________________________________ >>> From: [email protected] [ >>> [email protected]] On Behalf Of Jen Bourey [ >>> [email protected]] >>> Sent: Saturday, November 07, 2009 7:26 PM >>> To: [email protected] >>> Subject: [uportal-dev] Render/subscribe permissions proposal (UP-2499) >>> >>> Hello everyone, >>> >>> For those who haven't seen the new replacement for CChannelManager >>> (UP-2047), our new portlet administration portlet offers some new portlet >>> lifecycle features. Administrators will now be able to move content through >>> a structure workflow that contains the following states: created, approved, >>> published, and expired. These states are described in detail at >>> http://www.ja-sig.org/wiki/display/UPC/Portlet+Lifecycle. >>> >>> While end users will presumably only be able to see channels with a >>> lifecycle state of "published," it would of course be helpful to allow >>> administrators, content owners, and fragment owners to be view unpublished >>> content while it's being developed. We might want to render the chrome >>> separately to make sure these special groups of users can differentiate >>> between content currently available to end users and that which is not yet >>> published. However, before we get to that step, we need to update our >>> permissions model to support configurably displaying unpublished content by >>> user group. This work is currently represented by JIRA UP-2499. >>> >>> This issue also intersects in potentially interesting ways with our >>> existing logic for determining whether a user should be able to subscribe to >>> a channel. Currently we don't allow users to subscribe to channels which >>> are members of the top-level "All Categories" category, though they are >>> still able to view these channels. In the past, these channels were also >>> not able to be administered through the channel administration tool, though >>> we've fixed that as part of the UP-2047 work. Even with the added ability >>> to administer these channels, I believe it's still the case that fragment >>> layout owners will have trouble subscribing to these "hidden" channels, and >>> it seems like this behavior is likely to be confusing. While we're already >>> making changes to the channel permissions, it might make sense to separate >>> out the subscribe and render channel permissions. >>> >>> From looking through the codebase, it appears that both the >>> ChannelManager and user layout code defer to >>> AuthorizationImpl.canPrincipalRender(IAuthorizationPrincipal principal, int >>> channelPublishId), which in turn defers to >>> AuthorizationImpl.canPrincipalSubscribe(IAuthorizationPrincipal principal, >>> int channelPublishId) to determine if a user may view an individual channel. >>> It looks like if we update AuthorizationImpl, our changes should be applied >>> in both places. >>> >>> I'd like to propose the following new channel permissions: >>> >>> SUBSCRIBE_CREATED >>> SUBSCRIBE_APPROVED >>> SUBSCRIBE_PUBLISHED (replaces current general SUBSCRIBE permission) >>> SUBSCRIBE_EXPIRED >>> >>> RENDER_CREATED >>> RENDER_APPROVED >>> RENDER_PUBLISHED >>> RENDER_EXPIRED >>> >>> Once these permissions are all available, they could be assigned to >>> specific groups and channels/channel categories to allow administrators, >>> content owners, and fragment layout owners to subscribe to and render >>> content not currently available to most users. >>> >>> We could also use these enhanced permissions to eliminate the magical >>> top-level channel category behavior. Instead, content like the login >>> channel could be placed in a special group for which end users have render >>> permissions but no subscribe permissions. >>> >>> Does anyone have foresee problems with this approach or have suggestions >>> for improvement? >>> >>> - Jen >>> >>> >>> -- >>> Jen Bourey >>> >>> -- >>> >>> You are currently subscribed to [email protected] as: >>> [email protected] >>> To unsubscribe, change settings or access archives, see >>> http://www.ja-sig.org/wiki/display/JSG/uportal-dev >>> >>> -- >>> You are currently subscribed to [email protected] as: >>> [email protected] >>> To unsubscribe, change settings or access archives, see >>> http://www.ja-sig.org/wiki/display/JSG/uportal-dev >>> -- >>> You are currently subscribed to [email protected] as: >>> [email protected] >>> To unsubscribe, change settings or access archives, see >>> http://www.ja-sig.org/wiki/display/JSG/uportal-dev >>> >>> >> >> >> -- >> Jen Bourey >> >> -- >> >> You are currently subscribed to [email protected] as: >> [email protected] >> >> >> To unsubscribe, change settings or access archives, see >> http://www.ja-sig.org/wiki/display/JSG/uportal-dev >> >> >> -- >> >> Susan Bramhall ([email protected]) >> Senior Developer, Infrastructure Systems and Architecture (formerly T&P) >> Yale University Information Technology Services (ITS) >> 25 Science Park, 150 Munson St, New Haven, CT 06520 >> Phone: 203 432 6697 >> >> -- >> >> >> You are currently subscribed to [email protected] as: >> [email protected] >> >> To unsubscribe, change settings or access archives, see >> http://www.ja-sig.org/wiki/display/JSG/uportal-dev >> >> > > > -- > Jen Bourey > > -- > > You are currently subscribed to [email protected] as: > [email protected] > To unsubscribe, change settings or access archives, see > http://www.ja-sig.org/wiki/display/JSG/uportal-dev > > > -- > > Susan Bramhall ([email protected]) > Senior Developer, Infrastructure Systems and Architecture (formerly T&P) > Yale University Information Technology Services (ITS) > 25 Science Park, 150 Munson St, New Haven, CT 06520 > Phone: 203 432 6697 > > -- > > You are currently subscribed to [email protected] as: > [email protected] > To unsubscribe, change settings or access archives, see > http://www.ja-sig.org/wiki/display/JSG/uportal-dev > > -- Jen Bourey -- You are currently subscribed to [email protected] as: [email protected] To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/uportal-dev
