Programmatically update User Roles membership - InfoPath Dev
in

InfoPath Dev

Programmatically update User Roles membership

Last post 08-11-2013 01:06 PM by Patrick Halstead. 1 replies.
Page 1 of 1 (2 items)
Sort Posts: Previous Next
  • 08-06-2013 04:38 PM

    Programmatically update User Roles membership

    I have a requirement where I would like to update a role's membership with the people from a SharePoint group. We are using web services and code behind to fetch the users but would it be possible to then update(add) the role's membership with those users? I can't use AD groups and User Roles don't support SharePoint groups. I also would prefer not to hard code specific users in the roles in case they change over time.

    <xsf:roles default="Default" initiator="Requester">
      <xsf:role name="Requester"></xsf:role>
      <xsf:role name="Approver"></xsf:role>
      <xsf:role name="Finance"></xsf:role>
      <xsf:membership>
       <xsf:getUserNameFromData select="/my:myFields/my:participants/my:requester/my:staff/my:login" memberOf="Requester"></xsf:getUserNameFromData>
       <xsf:getUserNameFromData select="/my:myFields/my:participants/my:approvers/my:approverChoice" memberOf="Approver"></xsf:getUserNameFromData>
      </xsf:membership>
     </xsf:roles>

    Josée Sévigny
  • 08-11-2013 01:06 PM In reply to

    Re: Programmatically update User Roles membership

    Hi Josée,

    One first imagines you could use GetUserProfileService to get the groups and then have the form's user role dialog lookup users from that, but it won't work because User Roles are based on active directory and SharePoint groups are defined separately (even though they are defined based on AD groups). In other words, even if you get them in your form they won't correspond to the actual user who opens the form in the InfoPath rich client.

    So, I recommend removing the user role functionality from your form and using fields in your form's main data source to manage them with lookups to GetUserProfileService and/or a separate list to test whether or not the current user is in a role or not. For example, you can create a User Role's list that specifies role and user/group. On form load, you open this list and lookup the user and user's group and filter the list with that info to determine which roles are available. You will need some notion of role precedence in the case a user has two roles (i.e. order for which one to assign).

    Anyway, it's all very doable. Unfortunately, the User Role functionality isn't very extensible these days and that's ok because you can just use external data sources and form logic to achieve the same functionality and extend beyond the limits imposed by it.  The same is true for Submit Options. I tell people to not use Submit buttons but rather regular buttons configured to use Rules and Custom Code and just have the button execute rules. Much more flexible.

    Good luck! 

    Patrick Halstead
    Project Manager at Qdabra
Page 1 of 1 (2 items)
Copyright © 2003-2019 Qdabra Software. All rights reserved.
View our Terms of Use.