User Role Options? - InfoPath Dev
in

InfoPath Dev

Use our Google Custom Search for best site search results.

User Role Options?

Last post 12-20-2012 11:05 AM by Jimmy. 3 replies.
Page 1 of 1 (4 items)
Sort Posts: Previous Next
  • 12-20-2012 09:31 AM

    User Role Options?

    Hi,

    I'm trying to bypass InfoPaths standard user role option due to the fact that it's a first come, first serve basis when dealing with one user in multiple roles. I want to use an xml document to provide the list of names and roles they are in. See the following....

    <roles>
        <role = "Approver">
            <user>Mary</user>
            <user>Joe</user>
        </role>
        <role = "Submitter">
            <user>Mary</user>
            <user>Steve</user>
        </role>
    </roles> 

    I'm using the GetUserProfileByName webservice to get all the users info. My question is two fold.

    1.  Is it possible to auto populate a text field with data from an xml document(using a receive datasource)? I know it is possible to grab data from an xml document using a combo box or list field, but it doesn't necessarily auto populate the field with the data.
    2. Is there anything special that needs to be set up in a rule to grab the data from a field with multiple values?

     

    Here's my example: Let's say Mary is the current user....

    Textfield1 = xml datasource above

    Textfield2: If role = "Submitter" then disable Textfield2

     

    If there are easier ways to get around this then by all means I am all ears, I just can't seem to connect a few of the dots. Thanks in advance for any help I get!! Another option I'm thinking of is setting up each role with their own field that pulls data from their own xml documents, but I'd rather not do that.

  • 12-20-2012 09:44 AM In reply to

    I don't quite understand the example provided, but yes, you can absolutely use an XML data source to look up data.  For example, you could check whether the current user is a submitter by using a condition like this:

    xdXDocument:Get-DOM("Roles")/roles/role[user = currentUserField]/@name = "Approver"

    <role = "Approver"> isn't valid XML, but you could have <role name="Approver">, which is what I'm assuming for my example above.

    Jimmy Rishe / Software Developer / Microsoft MVP
    Qdabra Software
  • 12-20-2012 10:47 AM In reply to

     Thanks Jimmy,

     

    After getting your answer I researched the xdXDocument:Get-DOM method/function to get a better understanding of it. I just want to get this straight, I drop this expression into a formatting rule in the field I want to enable or disable according to the xml document?

    I added this expression to a field and changed the currentUserField to the field name I am using for the current user on this form and then checked for errors in the condition and this is what came up. Any ideas what I might have done wrong or what I missed? I tried researching this error as well.

     Namespace 'http://schemas.microsoft.com/office/infopath/2003/xslt/xDocument' does not contain function 'Get-DOM'.

     

    Again, Thanks.

  • 12-20-2012 11:05 AM In reply to

    Yes, that's correct.  I would suggest placing it into a Calculated Value control first to make sure it works, since the Condition entry fields don't validate formulas.  There was an error in my formula.  It's actually GetDOM("DataSourceName") and not Get-DOM("DataSourceName").  To refer to the main data source, you would use get-DOM() (all of these are case sensitive).

    Oftentimes, the starting point would be to use Insert field or group... in the formula editor to select the field you want to use in your formula, then tweak the formula as needed.

    Probably most of the time, you would want to hide controls when someone is not in a particular role, and the formula for that would be:

    not(xdXDocument:GetDOM("Roles")/roles/role[user = currentUserField]/@name = "Approver")

    Jimmy Rishe / Software Developer / Microsoft MVP
    Qdabra Software
Page 1 of 1 (4 items)
Copyright © 2003-2019 Qdabra Software. All rights reserved.
View our Terms of Use.