[uportal-dev] uPortal IRC logging to echelog
uPortal's IRC channel now logs to echelog: http://echelog.com/logs/browse/jasig-uportal This is bleeding edge just-added integration, so probably worth keeping an eye on for a few days as we work through whatever documentation needs updated to link to. -- You are currently subscribed to uportal-dev@lists.ja-sig.org as: arch...@mail-archive.com To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/uportal-dev
Re: [uportal-dev] Gitter chat experiment
It does not support XMPP or other connectivity, not that I know of. It does offer a Mac OS X desktop client. There also seem to be APIs. Perhaps eventually someone will build more integrations. It looks very early beta and rough around the edges and in the middle too. Nonetheless, long term, something that integrates with GitHub could be a good thing, and could drive down the amount of extra management and provisioning and permissioning overhead -- having commit on the repo implying privileges in the chat associated with the repo is pretty brilliant. Andrew On 4/18/14, 2:26 PM, Cris J Holdorph wrote: Does it allow someone to connect from their existing chat client, like pidgin? Cris J H On 04/18/2014 12:17 PM, Andrew Petro wrote: uPortal committers, As an experiment only (so far), let's check this out: https://gitter.im/Jasig/uPortal It *doesn't* seem to have the robust chat archive / search that we'd ideally want (but it does seem to be under active development and it's got more chat archive than the zero that we have operational on IRC now!) Love the GitHub integration, and the potential to turn on the Travis-CI integration etc. Andrew -- You are currently subscribed to uportal-dev@lists.ja-sig.org as: arch...@mail-archive.com To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/uportal-dev
Re: [uportal-dev] Gitter chat experiment
Does it allow someone to connect from their existing chat client, like pidgin? Cris J H On 04/18/2014 12:17 PM, Andrew Petro wrote: uPortal committers, As an experiment only (so far), let's check this out: https://gitter.im/Jasig/uPortal It *doesn't* seem to have the robust chat archive / search that we'd ideally want (but it does seem to be under active development and it's got more chat archive than the zero that we have operational on IRC now!) Love the GitHub integration, and the potential to turn on the Travis-CI integration etc. Andrew -- You are currently subscribed to uportal-dev@lists.ja-sig.org as: arch...@mail-archive.com To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/uportal-dev
[uportal-dev] Gitter chat experiment
uPortal committers, As an experiment only (so far), let's check this out: https://gitter.im/Jasig/uPortal It *doesn't* seem to have the robust chat archive / search that we'd ideally want (but it does seem to be under active development and it's got more chat archive than the zero that we have operational on IRC now!) Love the GitHub integration, and the potential to turn on the Travis-CI integration etc. Andrew -- You are currently subscribed to uportal-dev@lists.ja-sig.org as: arch...@mail-archive.com To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/uportal-dev
Re: [uportal-dev] Nice work on Portlet Marketplace
This sounds reasonable to me. James Wennmacher - Unicon 480.558.2420 On 04/17/2014 06:46 PM, Andrew Petro wrote: I agree we need to do something to hide some portlet marketplace entries from non-admins. I really like the idea of inventing a VIEW_MARKETPLACE_ENTRY permission activity that one can be granted targeting portlets (or portlet categories, of course), requiring VIEW_MARKETPLACE_ENTRY or MANAGE permission to see an entry for any given portlet in the marketplace. And then the business rule of non-portal-administrators do not see non-categorized portlets could be easily expressed as granting VIEW_MARKETPLACE_ENTRY on all categories of portlets. If a portlet is in a category, user would have the permission on it. If it isn't in any category, wouldn't. And then adopters can go forth nuancing the experience via permissions -- we think we have requirements here where users will have permission to see marketplace entries for some portlets they can't actually subscribe or render, and we definitely have requirements for users to be able to render some infrastructural portlets that they don't need to be bothering with in the Marketplace. Captured some of these thoughts here: https://wiki.jasig.org/display/UPC/Marketplace?focusedCommentId=67371619#comment-67371619 I'm thinking of this kind of fix as a "bugfix" that we could accept in the RC march to uPortal 4.1. So, like, polish up Favorites and Marketplace and dynamic skin to work well, but too late to bring in my glorious to do list portlet [1] or other new functionality for uPortal 4.1. Andrew [1]: That's kind of an inside joke. I don't actually have a glorious to do list portlet. But what I mean to evoke by this is, no new features! :) On 4/17/14, 5:50 PM, Drew Wills wrote: I'm looking at the Portlet Marketplace in a local dev environment today, now that it's in the master branch -- nice work! One item of feedback: I think it really should honor the feature whereby non-categorized portlets are hidden from browsing and direct access. drew -- You are currently subscribed to uportal-dev@lists.ja-sig.org as: arch...@mail-archive.com To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/uportal-dev
Re: [uportal-dev] Nice work on Portlet Marketplace
On 04/17/2014 06:46 PM, Andrew Petro wrote: I agree we need to do something to hide some portlet marketplace entries from non-admins. I really like the idea of inventing a VIEW_MARKETPLACE_ENTRY permission activity that one can be granted targeting portlets (or portlet categories, of course), requiring VIEW_MARKETPLACE_ENTRY or MANAGE permission to see an entry for any given portlet in the marketplace. I can work with this vision. drew -- You are currently subscribed to uportal-dev@lists.ja-sig.org as: arch...@mail-archive.com To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/uportal-dev
Re: [uportal-dev] Feature on groups selection to end user
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
Re: [uportal-dev] Feature on groups selection to end user
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
Re: [uportal-dev] Feature on groups selection to end user
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 touportal-...@lists.ja-sig.org >> as:ape...@wisc.edu >> To unsubscribe, change settings or access archives, >> seehttp://www.ja-sig.org/wiki/display/JSG/uportal-dev > -- You are currently subscribed to uportal-dev@lists.ja-sig.org as: arch...@mail-archive.com To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/uportal-dev
[uportal-dev] Apereo news feed?
I'm taking a pass through `Jasig/master` Apereo-ifying it, zapping some of the user-facing Jasig references in favor of Apereo. **I am not re-packaging all the code for 4.1. That would be insane.** Anyway, tripped over: Jasig website has this lovely news feed http://jasig.org/jasig-news/feed Apereo website has this lovely news page: http://www.apereo.org/news Anybody know how to get an RSS or Atom feed for that Apereo new so I can retire dependence on the Jasig website RSS feed? Andrew -- You are currently subscribed to uportal-dev@lists.ja-sig.org as: arch...@mail-archive.com To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/uportal-dev
Re: [uportal-dev] Feature on groups selection to end user
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 to uportal-dev@lists.ja-sig.org as: > ape...@wisc.edu > To unsubscribe, change settings or access archives, see > http://www.ja-sig.org/wiki/display/JSG/uportal-dev -- You are currently subscribed to uportal-dev@lists.ja-sig.org as: arch...@mail-archive.com To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/uportal-dev
[uportal-dev] Feature on groups selection to end user
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 to uportal-dev@lists.ja-sig.org as: arch...@mail-archive.com To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/uportal-dev
