none
Compare a people Picker Result to a Username in InfoPath 2010 of Sharepoint 2010 Enterprise

    Question

  • Greetings,

    I have a 2010 Infopath form using the built in people picker function. Once a person is selected on the people picker and the form is saved I want to do 2 things with that field.

    1. Make the field forever read only. If the field has to be changed a new form must be filled out.

    2. Compare the contents of the people picker field with the current user who has the form open. If the people picker field and the current user are the same, I want a drop down list to become active that allows the status of the form to be changed from pending to approved or denied. The status filed is a simple drop down on the form. If the people picker and the current user are not the same, I want the drop down status list either hidden or the control disabled.

    Since the person intially filling out the form cannot change this field, it can be hidden at first, but needs to be visiable in later openings of the form if the people picker and current user are the same.

    Any help is appreciated.


    dfife01

    Monday, July 02, 2012 8:52 PM

Answers

  • Hi difife01,

    The way i trouble shoot this is to expose both fields side by side in text boxes or calculated value's.

    If the values look the same on run time then.

    • msxsl:string-compare(../my:CRManager/pc:Person/pc:AccountId, ../my:CRCurrentUser, "", "i") != 0 should show field (result false)
    • msxsl:string-compare(../my:CRManager/pc:Person/pc:AccountId, ../my:CRCurrentUser, "", "i") = 0 should Hide/Disable field or trigger rule (result true)

    If the values Don't look the same on run time then.

    • msxsl:string-compare(../my:CRManager/pc:Person/pc:AccountId, ../my:CRCurrentUser, "", "i") != 0 should Hide/Disable field or trigger rule (result true)
    • msxsl:string-compare(../my:CRManager/pc:Person/pc:AccountId, ../my:CRCurrentUser, "", "i") = 0  should show field (result false)

    You could even have a test value:

    1. Field Name: "ManagerEqualsUser"
    2. Data type: (True/False boolean)
    3. Default Value: False
    4. Put an Action rule on "CRCurrentUser" (User the Same)
    5. Condition: msxsl:string-compare(../my:CRManager/pc:Person/pc:AccountId, ../my:CRCurrentUser, "", "i") = 0
    6. Add Set a field's value
    7. Field: ManagerEqualsUser
    8. Value: fx button: true()
    9. Then put another an Action rule on "CRCurrentUser" (Users are Different)
    10. Condition: msxsl:string-compare(../my:CRManager/pc:Person/pc:AccountId, ../my:CRCurrentUser, "", "i") != 0
    11. Add Set a field's value
    12. Field: ManagerEqualsUser
    13. Value: fx button: false()

    If it's easier for you to read and understand then i would keep the "ManagerEqualsUser" field and reference it every time you want to hide or show something this way your only using the compare rule twice.


    Kind Regards, Justin Nash

    Thursday, July 05, 2012 11:29 PM
  • Justin,

    Finally, it is working. This is VERY messy. Believe it or not, this is only the second form I have ever done. I have many more to do and they only get more complex from here. Am I in store for a world of hurt?

    There has got to be a better way to do a field compare. So, this is finally what worked:

    Create 3 hidden fields: CRCurrentUser, CRApprovingManagerCopy, and CRManagerEqualsUser.

    The CRCurrentUser and CRApprovingManagerCopy are populated by an “on form load” action rule with the CRCurrentUser coming for GetUserProfilebyName function and the CRApprovingManagerCopy coming from the people picker. Then run a translate on CRApprovingManagerCopy to make it lower case.

    The  field CRManagerEqualsUser  is the function : “CRcurrentUser contains CRApprovingManagerCopy” which properly returns a true or false.

    The Drop Down Status field is now properly disabled if CRManagerEqualsUser = false and enabled if CRManagerEqualsUser = true.

    I am really perplexed about some forms I know I am going to do that compare for 5 different managers, not just 1 like in this field. I would be MUCH interested in any info on the string-compare syntax and where it is usable in Sharepoint. From what I can read, it was usable back in Infopath 2003. Why is was impossible for me to get going, I don't know.

    Thanks for all your help!!!

    David


    dfife01

    Friday, July 06, 2012 8:43 PM

All replies

  • Hi dfife01,

    The first one is easy enough you need a form status or a check on form load to see if its the first time the form has been opened. Then have a formating rule that disables the people picker. Also you may want to make a rule on fist summit that the People picker cannot be blank. E.g. Form Status not = New disable field and have the status updated just before first submit.

    The second step may be a little more tricky depending on you InfoPath experience.

    1. Call the User Profile service on form load and update current user "AccountId" in hidden field ( http://blogs.microsoft.co.il/blogs/itaysk/archive/2007/04/05/InfoPath-_2D00_-Get-the-current-user-without-writing-code.aspx ) e.g. CurrentUserAccountId = AccountName
    2. Put a compare rule on the required sections, drop down lists etc... 

    msxsl:string-compare( "PeoplePickerAccountId" , "CurrentUserAccountId" , "", "i") != 0  Hide


    Kind Regards, Justin Nash


    Tuesday, July 03, 2012 12:18 AM
  • Justin,

    Thanks for the reply. I am skilled enough for the first option, but the second eludes me abit. I am a network admin that has been drafted into Sharepoint by folks that think if you understand networking, you know everything.. It's still a computer right?

    I am comfortable with the GetUserProfileByName and I use it to fill in the name of the person creating the form intially. but, without some step by step, I am a bit lost. I take it there is not a codeless way to do this? And I appreciate yuour any any other assistance I may get.

    David


    dfife01

    Tuesday, July 03, 2012 1:34 AM
  • Hi dfife01,
    The formula I provided is a codeless solution used in then "Condition" section of a rule type "Formatting":

    Its a string compare rule is used to ensure that if both AccountId's match. The "!= 0" part ensures that when they do match your section/field will not hide.

    You put the rule in as an expression, also you can test if you have the right syntax by selecting the field you have the rule on then select "is equal to" then select "Use a formula...".

    You will have a new window make sure you have the framework "msxsl:string-compare( PeoplePickerAccountId , CurrentUserAccountId , "", "i") != 0".

    • PeoplePickerAccountId is the field that is populated on first form open.
    • CurrentUserAccountId is the the current user who opened the form.
    • Both can be selected by "Insert Field or Group" found in the bottom left of the window.

    Once you have the formula working you can select "Edit XPath (advanced)" then highlight the text copy and go back to the Condition select The expression then paste the results.

    I understand that this can be a bit time consuming the first few times but this insures that the data is acurate. If you where to do jus PeoplePickerAccountId = CurrentUserAccountId you can end up with some funy results some times.

    If your having problems understanding any part please feel free to point them out and ill try to help explain it in more detail. This is a more advance InfoPath rule then most.


    Kind Regards, Justin Nash

    Tuesday, July 03, 2012 4:33 AM
  • Just,

    I used:

    msxsl:string-compare(my:CRManager/pc:Person/pc:AccountId, my:CRCurrentUser, "", "i") != 0

    as my formula and got an error stating it was not compatable with web forms.


    dfife01

    Tuesday, July 03, 2012 3:43 PM
  • Justin,

    How can I tell on the Form Load function in Infopath if it is the first time the form has been opened? Is there a standard value i can compare?

    David


    dfife01

    Tuesday, July 03, 2012 3:55 PM
  • Greetings,

    I resolved the form load issue. I created a field that is initially populated by a rule, then subsquently changed when re-accessed by another rule. Works great. Still need to figure out how to do the peple picker with cusrrent user comparison. One method I found to copmpare then failed because the domain name was capitalized in the accountID on one and not the other... silly case sensitive evaulation.


    dfife01

    Tuesday, July 03, 2012 5:42 PM
  • Hi dfife01,

    I'm glad to hear that you got the form load rules to work. As for the compare rule it can be a bit tricky at first but once you get it and use it a few times it makes comparing to values a little more simple in my opinion.

    I will try to brake down the steps a little more:

    1. Get the AccountName form the User Profile and populate field "CRCurrentUser"
    2. Have a UserName entered in to people picker "CRManager"
    3. Select a field that you wish to hide
    4. Select New Formatting
    5. Select Condition
    6. Select "Use a formula..." from the drop down list on your far right
    7. Input msxsl:string-compare(AccountId, CRCurrentUser, "", "i") != 0
    8. Replace AccountId by highlighting it then selecting "Insert Field or Group..." find the AccountId under CRManager in the list of fields. Select "Ok"
    9. Replace CRCurrentUser by highlighting it then selecting "Insert Field or Group..." find the CRCurrentUser in the list of fields. Select "Ok"
    10. Select "Verify Formula" third button from the left bottom corner you should have a result "The formula does not contain any errors." If Not revisit steps 8 and 9 they both will show as single one word results e.g. AccountId
    11. Tick box in bottom right "Edit XPath (advanced) and copy the formula. (You will notice the text will change to full paths relative to where your field/folder is located)
    12. Select Cancel in bottom right
    13. Change the drop down list on the right to "The expression" then clear then past the rule in the field.

    Kind Regards, Justin Nash

    Tuesday, July 03, 2012 11:22 PM
  • Justin,

    Excellent post. I completely understand what you are saying and followed the instructions to the letter.  As a result, I get an expression line like this:

    msxsl:string-compare(my:CRManager/pc:Person/pc:AccountId, my:CRCurrentUser, "", "i") != 0

    It passes the verify with no issues and saves locally just fine.

    However, when I attempt to publish the form, I get an "Usupported Expression" error. If I publish anyway and attempt to open the form, I get a "This form is not browser enabled" error. I have researched this expression and what I read says it is browser supported.  In fact, I have researched this so much I completely understand the srting and it's switches. I can find no reason why it is not working. The field I am putting the conditional formating on is a drop down list, could that cause a problem?

    I would also like to express how grateful I am for your assistance.


    dfife01

    Thursday, July 05, 2012 3:06 PM
  • Justin,

    I broke down and created a Microsoft Troubleticket. I was able to get the Unsupported Expression error corrected. I have to have a "../" in front of the "my:" part on the 2 strings being compared. Howerver, when I load the forn, the control is fully usable wether the compare critera is met or not. I don't know how to even test what that expression is doing. Any troubleshooting ideas?


    dfife01

    • Marked as answer by dfife01 Friday, July 06, 2012 1:32 PM
    • Unmarked as answer by dfife01 Friday, July 06, 2012 1:32 PM
    Thursday, July 05, 2012 8:21 PM
  • Hi difife01,

    The way i trouble shoot this is to expose both fields side by side in text boxes or calculated value's.

    If the values look the same on run time then.

    • msxsl:string-compare(../my:CRManager/pc:Person/pc:AccountId, ../my:CRCurrentUser, "", "i") != 0 should show field (result false)
    • msxsl:string-compare(../my:CRManager/pc:Person/pc:AccountId, ../my:CRCurrentUser, "", "i") = 0 should Hide/Disable field or trigger rule (result true)

    If the values Don't look the same on run time then.

    • msxsl:string-compare(../my:CRManager/pc:Person/pc:AccountId, ../my:CRCurrentUser, "", "i") != 0 should Hide/Disable field or trigger rule (result true)
    • msxsl:string-compare(../my:CRManager/pc:Person/pc:AccountId, ../my:CRCurrentUser, "", "i") = 0  should show field (result false)

    You could even have a test value:

    1. Field Name: "ManagerEqualsUser"
    2. Data type: (True/False boolean)
    3. Default Value: False
    4. Put an Action rule on "CRCurrentUser" (User the Same)
    5. Condition: msxsl:string-compare(../my:CRManager/pc:Person/pc:AccountId, ../my:CRCurrentUser, "", "i") = 0
    6. Add Set a field's value
    7. Field: ManagerEqualsUser
    8. Value: fx button: true()
    9. Then put another an Action rule on "CRCurrentUser" (Users are Different)
    10. Condition: msxsl:string-compare(../my:CRManager/pc:Person/pc:AccountId, ../my:CRCurrentUser, "", "i") != 0
    11. Add Set a field's value
    12. Field: ManagerEqualsUser
    13. Value: fx button: false()

    If it's easier for you to read and understand then i would keep the "ManagerEqualsUser" field and reference it every time you want to hide or show something this way your only using the compare rule twice.


    Kind Regards, Justin Nash

    Thursday, July 05, 2012 11:29 PM
  • Justin,

    Finally, it is working. This is VERY messy. Believe it or not, this is only the second form I have ever done. I have many more to do and they only get more complex from here. Am I in store for a world of hurt?

    There has got to be a better way to do a field compare. So, this is finally what worked:

    Create 3 hidden fields: CRCurrentUser, CRApprovingManagerCopy, and CRManagerEqualsUser.

    The CRCurrentUser and CRApprovingManagerCopy are populated by an “on form load” action rule with the CRCurrentUser coming for GetUserProfilebyName function and the CRApprovingManagerCopy coming from the people picker. Then run a translate on CRApprovingManagerCopy to make it lower case.

    The  field CRManagerEqualsUser  is the function : “CRcurrentUser contains CRApprovingManagerCopy” which properly returns a true or false.

    The Drop Down Status field is now properly disabled if CRManagerEqualsUser = false and enabled if CRManagerEqualsUser = true.

    I am really perplexed about some forms I know I am going to do that compare for 5 different managers, not just 1 like in this field. I would be MUCH interested in any info on the string-compare syntax and where it is usable in Sharepoint. From what I can read, it was usable back in Infopath 2003. Why is was impossible for me to get going, I don't know.

    Thanks for all your help!!!

    David


    dfife01

    Friday, July 06, 2012 8:43 PM