Skip to Content.
Sympa Menu

grouper-users - Re: [grouper-users] Subject external attributes retrieval

Subject: Grouper Users - Open Discussion List

List archive

Re: [grouper-users] Subject external attributes retrieval


Chronological Thread 
  • From: Martin van Es <>
  • To: Chris Hyzer <>
  • Cc: Grouper Users Mailing List <>
  • Subject: Re: [grouper-users] Subject external attributes retrieval
  • Date: Thu, 19 Feb 2009 10:54:07 +0100

Hi Chris,

A little breakthrough in the attributes quest! I've got an attribute returned!

<ns:wsSubject type="edu.internet2.middleware.grouper.ws.soap.WsSubject">
<ns:attributeValues>Martin van Es</ns:attributeValues>
<ns:id>mrvanes</ns:id>
<ns:identifierLookup xsi:nil="true"/>
<ns:name xsi:nil="true"/>
<ns:resultCode>SUCCESS</ns:resultCode>
<ns:sourceId>example</ns:sourceId>
<ns:success>T</ns:success>
</ns:wsSubject>

The query I used now was:
<ns1:getGroupsLite
xmlns:ns1="http://soap.ws.grouper.middleware.internet2.edu/xsd";>
<ns1:clientVersion>v1_4_000</ns1:clientVersion>
<ns1:subjectId>$_GET[user]</ns1:subjectId>
<ns1:subjectSourceId></ns1:subjectSourceId>
<ns1:subjectIdentifier></ns1:subjectIdentifier>
<ns1:memberFilter>All</ns1:memberFilter>
<ns1:actAsSubjectId>GrouperSystem</ns1:actAsSubjectId>
<ns1:actAsSubjectSourceId></ns1:actAsSubjectSourceId>
<ns1:actAsSubjectIdentifier></ns1:actAsSubjectIdentifier>
<ns1:includeGroupDetail>true</ns1:includeGroupDetail>
<ns1:includeSubjectDetail>true</ns1:includeSubjectDetail>
<ns1:subjectAttributeNames>description</ns1:subjectAttributeNames>
</ns1:getGroupsLite>

So there definately is a problem with the G-FIV-O wso2/php example code :(
What I find confusing is that despite the fact that the parameters are named
explicitly, I can't leave them out, even the ones that contain no string. Eg.
removing subjectSourceId results in "Problem with boolean
'includeSubjectDetail', Invalid string to boolean conversion: 'description'
expecting true|false or t|f or yes|no or y|n case insensitive", which implies
that the parameter is referenced by it's position and not the name... using
names in this case is only more confusing!

So I would suggest to either stick with positional referencing as a
guideline,
or fix the passing of parameters to respect their name?!

But... one remark: why would you return subjectAttributeNames as a child of
getGroupsLiteResponse/return? I would expect it to be a child of
getGroupsLiteResponse/return/wsSubject, so it is near the subject's
attributeValues, just like the children of
getGroupsLiteResponse/return/wsGroups/detail?

Regards,
Martin




Archive powered by MHonArc 2.6.16.

Top of Page