Grouper Users - Open Discussion List

[Jeff McCullough <>]

Thank you. Yes, we only need this for the new UI.

Regards,

Jeff

On Feb 5, 2015, at 9:16 PM, Chris Hyzer <> wrote:

Yeah, get a list from SQL, you can generate a GSH script from that list if you like.

 

Something like this (didnt test it):

 

grouperSession = GrouperSession.startRootSession();

 

group = GroupFinder.findByName(grouperSession, "the:group:name");

grantPriv(group.getName(), group.toSubject(), "read");

grantPriv(group.getName(), group.toSubject(), "update");

 

Regarding leaving the group, yeah, if someone leaves the group then they dont have privs anymore on the group, so the logic gets confused.  I can work on that one to make it more graceful (just end up on the main Grouper UI screen?)  I assume we only need to worry about it in the new UI.

 

https://bugs.internet2.edu/jira/browse/GRP-1111

 

Thanks,

Chris

 

 

From: Jeff McCullough [] 
Sent: Thursday, February 05, 2015 8:04 PM
To: Chris Hyzer
Cc: 
Subject: Re: [grouper-users] default membership privileges for new members, setting default browser view and removing quick links

 

Hi Chris,

 

This works beautifully. Thank you. There are two remaining questions. 

 

What to do for groups that already exist in that folder? Get a list via sql and cycle through them?

 

In addition to adding read, I tried adding “update” such that whoever is in the group can change the membership of the group. This works for adding people to the group. For deletion there is one issue. If the logged in user tries to remove themselves from the group by either the “revoke membership” or “leave group”, there is an error. Their account is removed from the group though. 

 

Error: Subject: Subject id: 212372, sourceId: ldap does not have view on group edu:berkeley:org:Calnet:test-for-update-folder:test-group-update, Problem calling method leaveGroup on edu.internet2.middleware.grouper.grouperUi.serviceLogic.UiV2Group

 

They can remove others with no issue, so it is just their own membership that is at issue. Is this expected behavior or a possible bug?. Here is the full error listing: (also attaching a screen shot of the privileges the account does have.)

 

2015-02-05 16:25:10,239: [http-8443-4] INFO  EventLog.info(156) -  - [6e748cf6c3684da389dac5fbdb5c10c8,'212372','person'] delete member: group='edu:berkeley:org:Calnet:test-for-update-folder:test-group-update' list='members' subject='212372'/'person'/'ldap' (19ms)

2015-02-05 16:25:10,316: [http-8443-4] INFO  EventLog.info(156) -  - [b9b4b9a868d54201a877069443a73f1c,'GrouperSystem','application'] session: start (0ms)

2015-02-05 16:25:10,335: [http-8443-4] ERROR GrouperUiRestServlet.doGet(321) -  - Problem calling reflection from URL: edu.internet2.middleware.grouper.grouperUi.serviceLogic.UiV2Group.removeMember

 

edu.internet2.middleware.grouper.exception.InsufficientPrivilegeException: Subject: Subject id: 212372, sourceId: ldap does not have view on group edu:berkeley:org:Calnet:test-for-update-folder:test-group-update,

Problem calling method removeMember on edu.internet2.middleware.grouper.grouperUi.serviceLogic.UiV2Group

        at edu.internet2.middleware.grouper.userData.GrouperUserDataApi$5.callback(GrouperUserDataApi.java:864)

        at edu.internet2.middleware.grouper.GrouperSession.callbackGrouperSession(GrouperSession.java:974)

        at edu.internet2.middleware.grouper.userData.GrouperUserDataApi.recentlyUsedGroupAdd(GrouperUserDataApi.java:852)

        at edu.internet2.middleware.grouper.grouperUi.serviceLogic.UiV2Group.removeMember(UiV2Group.java:407)

        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)

        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)

        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)

        at java.lang.reflect.Method.invoke(Method.java:606)

        at edu.internet2.middleware.grouper.util.GrouperUtil.invokeMethod(GrouperUtil.java:4002)

        at edu.internet2.middleware.grouper.util.GrouperUtil.callMethod(GrouperUtil.java:3953)

        at edu.internet2.middleware.grouper.j2ee.GrouperUiRestServlet.doGet(GrouperUiRestServlet.java:288)

        at edu.internet2.middleware.grouper.j2ee.GrouperUiRestServlet.doPost(GrouperUiRestServlet.java:160)

        at javax.servlet.http.HttpServlet.service(HttpServlet.java:637)

        at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)

        at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)

        at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)

        at org.owasp.csrfguard.CsrfGuardFilter.doFilter(CsrfGuardFilter.java:110)

        at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)

        at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)

        at edu.internet2.middleware.grouper.ui.GrouperUiFilter.doFilter(GrouperUiFilter.java:1015)

        at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)

        at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)

        at org.jasig.cas.client.util.HttpServletRequestWrapperFilter.doFilter(HttpServletRequestWrapperFilter.java:75)

        at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)

        at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)

        at org.jasig.cas.client.validation.AbstractTicketValidationFilter.doFilter(AbstractTicketValidationFilter.java:201)

        at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)

        at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)

        at org.jasig.cas.client.authentication.AuthenticationFilter.doFilter(AuthenticationFilter.java:107)

        at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)

        at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)

        at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:219)

        at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)

        at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:558)

        at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)

        at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)

        at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)

        at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:298)

        at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:857)

        at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:588)

        at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:489)

        at java.lang.Thread.run(Thread.java:745)

 

Jeff

 

<image002.png>

On Feb 5, 2015, at 10:56 AM, Chris Hyzer <> wrote:

 

first of all, you wouldnt need a rule on each group, you just need to assign the group as a reader of itself.  However, using EL I was able to craft a rule to do this for all groups in a folder (on group create, assign the group to be a reader of itself, which means all members of the group can read the group).

The only thing you need to change is the folder name below.  Let me know how it goes :)

 

btw, this only assigns the priv is the group doesnt already have the priv, so if you have GrouperAll having READ/VEW on groups in your grouper config, then it wont work (and you wouldnt even need this rule!)  :)

 

Thanks,

Chris

 

grouperSession = GrouperSession.startRootSession();

folder = StemFinder.findByName(grouperSession, "testFolder");

AttributeAssign attributeAssign = folder.getAttributeDelegate().addAttribute(RuleUtils.ruleAttributeDefName()).getAttributeAssign();

AttributeValueDelegate attributeValueDelegate = attributeAssign.getAttributeValueDelegate();

attributeValueDelegate.assignValue(RuleUtils.ruleActAsSubjectSourceIdName(), "g:isa");

attributeValueDelegate.assignValue(RuleUtils.ruleActAsSubjectIdName(), "GrouperSystem");

attributeValueDelegate.assignValue(RuleUtils.ruleCheckTypeName(), RuleCheckType.groupCreate.name());

attributeValueDelegate.assignValue(RuleUtils.ruleCheckStemScopeName(), Stem.Scope.SUB.name());

attributeValueDelegate.assignValue(RuleUtils.ruleThenElName(),"${ruleElUtils.assignGroupPrivilege(groupId, 'g:gsa', groupId, null, 'read')}");

 

 

<image001.png>

 

From: Jeff McCullough [] 
Sent: Wednesday, February 04, 2015 7:03 PM
To: Chris Hyzer
Cc: 
Subject: Re: [grouper-users] default membership privileges for new members, setting default browser view and removing quick links

 

The alternate I guess is creating a rule per group after the groups are created. Let’s say there are multiple thousands of groups, will there be an issue with having that many rules? If the group is deleted the other issue is that the rule no longer applies. Is there an issue there?

 

Jeff

 

On Feb 2, 2015, at 11:32 PM, Jeff McCullough <> wrote:

 

Interesting idea. The groups in question will all be in one folder. I can see how to use the method for groups that exist. Is it possible to do this on groups that have yet to be created given the view/read group needs to be specified when creating the rule in the inheritGroupPrivileges method?

 

Thanks,

Jeff

 

On Feb 2, 2015, at 8:30 PM, Chris Hyzer <> wrote:

 

 

> 1) I'd like to be able to change the default membership privileges

> that are presented when adding a new member of a group. The current

> default is simply “member”. We might like the default to add “view”

> and “read” for the members that are being added. There are the

 

> privileges that are set for the GrouperAll (groups.create.grant.all.*)

> when a group is created, but the case I’m interested in is just for

> members of the group not anyone on the system. I don’t see any

> properties in the properties files, but wonder if maybe a rule would work?

 

Do you want this for all groups, or just certain groups?  If it is just certain groups, where you want all members to be able to view/read the group, can you just make the group a reader of itself (which implies view)?

 

 

> 

> 2) I’d like the default browser view to be different than the root

> view. The property default.browse.stem=edu:berkeley works fine in

> the Admin UI, but the new UI “Browse Folders”  view on the main page

> doesn’t change. Is there a separate property for that? Given it is a

> tree view, the desired behavior would be to at least open the view to

> the default browse stem.

 

I added a jira for that. 

 

https://bugs.internet2.edu/jira/browse/GRP-1107

 

 

> 

> 3) The quick links menu is great, but I don’t want to display the links

> for the Admin UI and Lite UI. I see properties for display relating to

> the older UIs, but not for the new UI. It looks like I just need to

> remove the links from the JSP. Is that correct?

> 

 

I added a jira for that.  And in the meantime, just edit that JSP

 

https://bugs.internet2.edu/jira/browse/GRP-1108

 

Thanks,

Chris