Using the standard solution of autopopulating a person field with the current user(data connection with web service and the form load rule similar to this ) I discovered that the solution works fine for new items, but fails for editing items.
After debugging it a bit, it seems that the DisplayName, AccountId, and AccountType values behind the person field are essentially locked until text field is user populated with something and blurred or check-named.
I set up a button with a rule to write my own username into the field, so just plain static text to take the data connection out of the equation(though the data connection does work fine), and a second button with a rule to copy the display name into another text field.
Once the form has been brought up, the autopopulate does not work, first of all. Then if I click the filler button I described, nothing happens. If I use the other button to push the DisplayName after that, it pushes a blank to the text box. So DisplayName is actually empty. However, if I type anything else and then blur, whether it resolves in the AD or not, using the filler button still shows no changes to what is in the box, but using the other button after that will cause the invisible entry to resolve and my name is pushed to that other text box.
None of this is an issue when creating new items. However, these items are initially created by a workflow copying some relevant fields when a report is made in a different list. Then they are reviewed and handled, so the item never has a new form, only edit form.
There is clearly some kind of a bug in the SP/InfoPath javascript, though I have a sinking feeling this is by design as a "security" feature. Every other field works just fine with editing using rules, just the person field has an issue.
Has anyone else experienced this or have any insight?
