I were wrong on one point : > On a side, with grouper you can define permissions (Admin, update, read....) on each groups, something that is missing in uPortal, like that user can see groups where they have permissions but i'm not sure if this will be really efficient in our context with a lot of groups and if make end adjustments.
Andrew added a comment on the wiki page : The UP_GROUPS permission owner defines a VIEW_GROUP activity Le 18/04/2014 16:34, Julien Gribonvald a ??crit : > Andrew, > > Thanks for this reply, else yes your idea was strange for me. > > This feature is a purpose so I don't need it in the hurry, it's only > because we are implementings in differents portlet a way to obtain > groups but never get something generic and entirely integrated in the > portal. > > The idea is to show to the user some groups on which he is allowed to > share/publish informations/resources depending on his profile/rights, > or eventually some groups that he should be able to define, thats all. > As example a basic would be a teacher who wants to define a news feed > that he will publish to his students, he needs an easy and fast way to > see and select his classroom without to know the exact id of each groups. > > After using Grouper could be a good solution, but when i see > possibilities with other group store like pags or smartldap I'm not > sure this is the best to evict other way to do, it's too > "grouper-centric", but why not if the GroupStore of the portal is > replaced by grouper... In all case that's why I posted this purpose. > In our case we use grouper but in the portal we use the > smartLDAPGroupStore that was modified (by ESUP) which is really more > fast than the grouper ws, we publish grouper groups on our ldap and > like that we can use the smartldap with all groups memberships in cache. > > On a side, with grouper you can define permissions (Admin, update, > read....) on each groups, something that is missing in uPortal, like > that user can see groups where they have permissions but i'm not sure > if this will be really efficient in our context with a lot of groups > and if make end adjustments. > > Our main needs would be that a user see at least all groups of his > school, after we can define some filters, implements something that > define a root node from user's school only depending on a user > attribute that is really more efficient than doing a request to abtain > these groups on grouper that will check on each group tree for user > permission... But this could evolve on a permission managed in the > portal... or like you said in a grouper management. But in this case > which one ? > > Julien > > > Le 18/04/2014 15:09, Andrew Petro a ??crit??: >> Someone gently pointed out to me off-list that this is completely >> wrong-headed: >> >> > Each feed added to the portlet would be a Subject >> >> and I agree -- I should have described the feeds being Resources over >> which person and group Subjects might enjoy permissions, not the >> feeds themselves being Subjects.?? Feeds don't have permissions over >> other resources. >> >> Andrew >> >> >> >> On 4/18/14, 7:07 AM, Andrew Petro wrote: >>> Julien, >>> >>> 1. Thanks for posting this. >>> >>> 2. I assume this feature can wait until after 4.1 is released? >>> >>> 3. Suggestion: use Grouper permissions. >>> >>> I think what this proposal amounts to is >>> >>> a) Individual syndicated feeds within feed reader instances are >>> entities over which users may have permissions (namely, the >>> permission to see that feed included in their experience of the >>> portlet). >>> >>> b) There ought to be a better UI for assigning those permissions. >>> >>> Great. >>> >>> So, >>> >>> The feed reader portlet publication would correspond to a Group in >>> Grouper. >>> >>> Each feed added to the portlet would be a Subject and a member of >>> the Group representing that feed publication. >>> >>> Ability to render that feed would be a Grouper Permission on the >>> Subject representing the feed. >>> >>> The permissions resolution needs of the portlet are now easy to >>> fulfill: the portlet simply asks Grouper whether the presenting user >>> has permission to render each feed entry. >>> >>> (Adding some other permissions, could also model administration >>> privileges over those feeds, etc.) >>> >>> >>> Then we need a better UI for the delegated administrator to assign >>> users and groups into the roles that would give them permissions >>> over these feed-subjects.?? Good UIs are a hard problem.?? No doubt >>> the uPortal UIs for group selection should continue to be improved. >>> >>> BUT.?? If we architect uPortal and portlets to embrace Grouper for >>> this, then administrators and users can equally administer these >>> permission grants via Grouper UIs and via tools built to talk to >>> Grouper APIs. >>> >>> I think that's the promising architectural direction for uPortal to >>> explore, and I expect it's a major initiative to go after >>> post-uPortal-4.1.?? I'm eager to ride on the greatness of Grouper >>> and on its attention to improving user experience. >>> >>> Kind regards, >>> >>> Andrew >>> >>> >>> >>> On 4/18/14, 2:09 AM, Julien Gribonvald wrote: >>>> Hi Everybody, >>>> >>>> I'm looking for a feature to give an easy way for users to select >>>> groups in order to define rights access on some resources in >>>> portlets, something similar to define groups on portlet >>>> definitions. In our context we have a massive delegation of rights >>>> and so many users aren't uPortal admin, so they don't and can't >>>> acess to uPortal groups view and in the case that they want to give >>>> access on a resource (from a portlet) they should watch on our >>>> grouper UI?? to find and see the exact name of the group (only way >>>> where we can define some access permissions on groups view, but >>>> this isn't perfect) and come back to the resource definition page >>>> (on the portlet). Actually our other problem - if we want a such >>>> feature - is that we should implements a group view in all our >>>> portlets where we need this feature and more it will be something >>>> "context specific" whereas i think some other uPortal deployers >>>> could need a such feature and they do not use necessary grouper, >>>> group pags or smartldap (we use this one a bit modified to avoid >>>> grouper ws) as example, so we would prefer to see something more >>>> integrated in the portal and that could be used in the community. >>>> >>>> I wrote a page on the wiki to explain how i see the feature with a >>>> use case : >>>> https://wiki.jasig.org/display/UPC/pick+up+groups+from+a+delegated+group+manager+view >>>> So any question and discussion about this feature would be >>>> appreciated. More I need advices on the best way to develop this >>>> feature and if someone have interest or could provide any help >>>> don't hesitate to take part of this discussion ;) >>>> >>>> Thanks >>>> >>>> Julien >>>> -- >>>> >>>> You are currently subscribed [email protected] >>>> as:[email protected] >>>> To unsubscribe, change settings or access archives, >>>> seehttp://www.ja-sig.org/wiki/display/JSG/uportal-dev >>> >> >> -- >> >> You are currently subscribed [email protected] >> as:[email protected] >> To unsubscribe, change settings or access archives, >> seehttp://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
