A Better User Role - InfoPath Dev
in

InfoPath Dev

A Better User Role

Last post 08-01-2012 03:08 PM by Nancy Young. 6 replies.
Page 1 of 1 (7 items)
Sort Posts: Previous Next
  • 03-15-2011 05:51 AM

    A Better User Role

    This is more of a helpful tutorial than a question,  Its something I have used to help with the way our forms function within our company. This may or may not work for you, but I wanted share it since it has worked so well for us.

    Definitions:

    • InfoPath UserRole: the user roles defined within InfoPath
    • UserRole: The actual user role of the end user Ex: Manager, Approver

     

    One of the problems we have with InfoPath is the InfoPath UserRole and how it relates to the actual UserRole.  This of course relates also to how InfoPath deals with the separation of Data and Functionality.  We needed a form that could be tested easier, UserRoles changed easier, and new Users added easier.  To do this without modifying the form became the challenge.  So we took the seperate Data approach, remove the data from InfoPath and put it into a Sharepoint List that is managed by one group.

    For this to work, you have to be able to pull the secondary data source from sharepoint (as a list) and get a username of some sort within InfoPath (using Webservices, code, etc.) then link the two together.

    How and why does this work better than the InfoPath UserRoles?

    You can add/change/delete users with ease?

    Ex: You have a form with 25 users, 20 are A users, and 5 are B users.  In InfoPath, you have to add them as such.  If someone quits/changes positions/etc.  You have to modify your form.

    Using the seperate Data approach if someone quits/changes positions/etc, you only change/delete from the list and its done, no uploads, no form modification, no end user updates, etc.

    When you have multiple roles on one form, this becomes invaluable for testing.  You can go from being role A one minute to being role B the next, and you don't have to modify your form.

     

    This also takes the person out of the form, and only uses the Role of the person.

    Ex: Bob is the Manager, with InfoPath UserRoles, you use Bob throughout the form as Bob, his role within the form could be Manager, but he is still Bob.

    Using an external list, Bob no longer matters, only the Manager matters. Why, because the User Role is what matters.

    Bob is the Manager, so is Betty and Brenda, all three could are Managers, but only Manager matters within the form.

    You can combine the Persons within one UserRole using InfoPath UserRoles, but then Example one comes into play again.

     

    It it a time saver.

    Ex: You have 5 forms, all forms use the same UserRoles.  Using InfoPath UserRoles,  you have to enter them in every form, which can take a long time.  You could copy a premade form with the UserRoles assigned already, but when someone quits/changes positions, Example one gets multiplied by the number of forms you have.

    Using the seperate Data approach, you only have to add 2 fields, and 1 data connection and its done.

     

    How do we do this?

    This does takes some work on the designer of the form in the beginning, but in the end, you have a form that is A: easier to test, B: easier to add/delete/change Roles of users and C: you don't have to modify the form to change roles again.

    In Sharepoint, create a new custom list, Form Users is a good name.

    The default columns I recommend are Name, and Role.  You can add Email as well or anything else you may need.

    In InfoPath, you will need 2 new fields and 1 new data connections (or 2 if you use UserProfileService.asmx to get user names, or another webservice)

    Add the sharepoint list Form Users as a data connection, with Name and Role being used from the list.

    Add 2 fields, UserRole and UserName (change names as needed), and UserEmail if you added it to your list.

    In the Rules on form open, add the rule, SetUserName (change name as needed), this rule should set the UserName field using whichever way you use to get the current user's name, whether by UserProfileService.asmx, code, etc.

    In the Rules on form open, add a rule under the previous, setUserRole(change name as needed), this rule should set the UserRole field.

    • Set the field to the Role from the Form Users data connection
    • Filter and add where Name on the Form Users data connection is equal to UserName. (This is why the name that goes into the UserName field should match the Name on the Form Users list from sharepoint)

    You can then use the UserRole field as a way to hide, validate, etc other fields.  So that only certain User Roles need to fill out certain fields. Ex: Managers may only be required to fill out 1 field, but an Employee may be required to fill out 10 fields.

     

     

    Hopefully this helps someone out, if you have any questions, let me know.

    GM

    Filed under:
  • 03-22-2011 09:37 AM In reply to

    Hey, I just wanted to say thank you for taking the time to post this! I'm sure others will find it helpful, and I appreciate that you are willing to share this information with the community.

    Have a great day!

    Hilary Stoupa

  • 09-02-2011 12:26 PM In reply to

    Could you elaberate more on what you mean here. Trying to accomplish this, but just not working out.

    Filter and add where Name on the Form Users data connection is equal to UserName. (This is why the name that goes into the UserName field should match the Name on the Form Users list from sharepoint)

    So far, I have a field called current user that takes the users email and populates in. Then I have a field called UserName (this is taken from sharepoint list). Sharepoint list has 2 fields (Role) and (email).

     What I am trying to do is limit the form to only open to users that are on this list. Otherwise it switches view to a default message we want to show. 

     

  • 09-06-2011 07:03 AM In reply to

    What are your columns from your sharepoint list?

     You list 2 of them, is that all?  Do you have username as well in the sharepoint list?

    Ex:

    Username      Role            Email
    Bob Marley    Manager      [email protected]
    Jane Doe       Employee    [email protected]
    John Smith    Employee    [email protected]

    This is the least amount of info needed to make the roles work correctly.

  • 09-07-2011 05:42 AM In reply to

    I have 3 columns

    Form       Email                       Role
    123       [email protected]        Employee
    123       [email protected]        Employee
    123       [email protected]         Employee
    234       [email protected]       Employee

    And so on. The way we get current user is by using the (Get user profile service.aspx) and then in order to know when current user is in the form, we prepopulate a hidden field with their work email from that service at form load. (We have to work in IP 2003)

    Maybe a sample you have could help. Not sure how much more I could explain. One thing I think I did not say was that I am basically trying to restrict the form to only certain users. If it is not one of these users, then the form goes to a different view. Is that possible with this control or am I thinking incorrectly? Thanks for the help.

  • 09-07-2011 08:44 AM In reply to

    You can do the same thing I am doing with usernames by using emails.

    You would be matching the email to email instead of username to username is the only difference I see.

     Here is what your input would look like, from 1 to 5.  Changing Username to UserEmail (from secondary data source) and currentUser to email (your hidden field) since you are using email as your key to who is using the form at the moment.

    In order to make it work, you would want to use to go to tools -> form options -> open and save -> rules and add the rule set UserRole.

    I have hidden items since they don't pertain to what you needed.

     

    If you have more questions, feel free to ask.

  • 08-01-2012 03:08 PM In reply to

    Brilliant.  Thanks.

    -Nancy
Page 1 of 1 (7 items)
Copyright © 2003-2019 Qdabra Software. All rights reserved.
View our Terms of Use.