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
