InfoPath Dev

I don't know what happened, this form has been working for months now.  The only thing that I was tinkering with was alternate access mappings.

The form in question does a SaveAttachment and a SubmitToSharePoint list.  The SaveAttachment works fine, but the SubmitToList is not submitting.  Well, it is for ME, but not for everyone else. 

I noticed something wierd in the list . . . the list entries that I submit are created by me, the created by column says my username.  Previous entries (from last week) have system account as the created by person, even for my entries. 

So it seems as if it is now trying to submit the list items as the logged in user, and they don't have rights to the list.

Alternate access mappings may be to blame.  At least they will affect some operations. 

My theory... 

Say you have a site with two access points, http://server  and http://extranet.domain.com, but no alternate access mappings configured.  The default zone shows http://server.  You then create a data connection to http://server/libraryname.  If you access the form from http://extranet.domain.com, the data connection url will remain http://server/libraryname.  If you add an alternate access mapping for http://extranet.domain.com, the data connection will be changed to reflect the zone you are coming in through.  So users accessing through http://server, will get connected to http://server/libraryname.  Users coming in through http://extanet.domain.com will attempt to connect to http://extranet.domain.com/libraryname. 

Before adding the AAM, coming in through http://extranet.domain.com would attempt to connect to http://server/libraryname and would likely be treated as a cross-machine scenario and not be able to impersonate the user on the data connection.  This could be why the system account was showing.  Adding an AAM for extranet.domain.com likely allows connecting via http://extranet.domain.com/libraryname under the current users credentials.

What version of qRules are you using?

With qRules 4.1, we've added SharePoint object model support for the SharePoint apis, which bypass the web service data connections and also allow working with Office 365.

Jim Cantwell:

Alternate access mappings may be to blame.  At least they will affect some operations. 

Before adding the AAM, coming in through http://extranet.domain.com would attempt to connect to http://server/libraryname and would likely be treated as a cross-machine scenario and not be able to impersonate the user on the data connection.  This could be why the system account was showing.  Adding an AAM for extranet.domain.com likely allows connecting via http://extranet.domain.com/libraryname under the current users credentials.

What version of qRules are you using?

With qRules 4.1, we've added SharePoint object model support for the SharePoint apis, which bypass the web service data connections and also allow working with Office 365.

Thanks.  That cleared AAM up a bit for me.  I think I understand the behavior I was experiencing. 

I'm on QRules 3.3.x