InfoPath Dev

 Hello,

I've created a web form with qRules embedded and I've then published it with the "Admin Approval" functionality of InfoPath. Once I've uploaded my form into SharePoint I'm able to use it via a web part. So far so good. The form does exactly what it should (in this case update a SharePoint list).

I then decide to add some additional functionality to the form (it now sends an email to tell my team about the changes that have been made to the SharePoint list). I tested the functionality directly from InfoPath and everything ran as expected. I then saved the form, published it again and loaded it back into SharePoint overwriting the original form. I tested the form in SharePoint and initially I thought everything was working OK because the email  was duly sent. However, when I examined my SharePoint list I could see that the data hadn't been updated.

I don't really understand this. It's like the qRules submit command is being ignored, but it worked before so why not now?

Admin Approval forms with qRules injected seem to be a bit erratic to me (this seems more like a SharePoint issue though). If I modify an "Admin Approval"  form and republish it, it doesn't seem to work the second time around. I had exactly the same issue with a previous form I was working on and ended up having to completely remove the form and the library that was using it and start again. Maybe I have done something wrong but I can't think what. Any thoughts?

Hey again - so yeah, I've never had this issue, with the form not updating when I upload a new version to central admin. Make sure any controls that execute qRules commands have post back set to always. You can also add the QdabraRules execution history somewhere on your form (we usually use a hidden "debug" view) so you can see if there are any errors (of course, you want to make sure your form stays open after you take whatever action you are attempting so you can see the result in the error node).

 As always thanks for a quick response. I'll check the status of post back. I don't believe I've changed that setting so I guess it's set to the default behaviour (whatever that is). Thank you.

Post back option was set to "only when necessary" so I've changed it to "always".

So, I've re-saved my form and published it with admin approval and loaded it back into SharePoint via Central Admin. However, now when I try and access the form in SharePoint I get the following error:

I now seem to have some "correlation error" but I've no idea what that means. Basically it seems that whenever I modify an admin approved form and re-upload it back to SharePoint I can pretty much guarantee it won't work. :-(

You need to copy out that GUID from your error and go check your SharePoint logs for that.

 I've uploaded the form again (without doing anything to it) and this time the form is rendering correctly. However, I'm now back to my original problem, ie the form appears to run correctly but doesn't actually update my SharePoint list. It works if I run the form directly from InfoPath though. Any problem-solving tips at this point?

My qRules submit command is executed on the press of a button and straight after this command I have another command to change the view. I was wondering if the change view command is somehow interfering with qrules and preventing it from executing? In InfoPath it doesn't seem to mind that I change view straight after the submit but perhaps this is more significant when accessing the form via a browser? Very strange.

You added the execution history like I suggested to see if qRules is returning any errors? Are these submit rules? If so, you may want to try using a regular rules button (not a "submit" button, you can still label it submit of course) instead - I think I've had inconsistent behavior when using qRules commands in Submit rules.

I've added the execution history to my form and I've launched the form from both InfoPath and SharePoint to compare the results. In InfoPath the form works as I expected and my SharePoint list is updated. When launched from a SharePoint page the form doesn't work as expected as my SharePoint list isn't updated.

In the screen dump I've attached to this post you will see that my form contains 5 qRules commands. The first 4 commands are CopyTable commands. Only the 1st and 4th CopyTable commands actually show as having completed successfully. This is OK though as the 2nd and 3rd CopyTable commands are essentially trying to copy empty tables so I expected that outcome. It's the 5th command I'm interested in though as this updates my SharePoint list.. When running my form from InfoPath (the top table in my screen dump) this shows has having successfully completed (although the Result column doesn't show a "1" - not sure what that's trying to tell me).

When performing the same action from SharePoint (the bottom table in my screen dump) the submit command doesn't work as there is no tick in the Success box. Unfortunately for me the error message is less than enlightening:

 "Error ocurred submitting data to list: Request failed. | Error ocurred submitting data to list: Request failed."

Let's ignore the spelling mistake (or perhaps that's how occurred is spelt in US English? :-)), but what the heck is "Request failed" telling me that I don't already know?

I think I've mentioned already that my form did work from the browser OK when I first created it (ie my SharePoint list was being updated). All I've done since then is add another view and an Email submit (which works fine from the browser incidentally).  Mystified.

Oh, and to answer your other question my button is just a regular button - it's not a submit button. :-(

 

 

When you re-injected the form, did you select Browser > Sandbox? or did you select the Admin version? any info in the SharePoint log files? When you were using the trial, were you also using it from the SharePoint page? Do you have a copy of the form prior to re-injecting with the full version?

Hello again, I've checked and I think I injected with Browser/Sandbox (that's the default and I don't remember changing it) but perhaps I should have chosen Browser/Admin Deploy? What's the difference between these two options? The box "Include Term Set APIs" isn't checked. I don't know what the significance of that is but assume I don't need it in this case?

I do have an earlier version of my form (which worked in the browser) and that is injected with full qRules. The submit command seems to have stopped working since I added a view and an email submit to the form.

 Hi Hilary,

I'm afraid to say I've been a fool. I decided to go back and check every single setting in my form to check that perception and reality actually matched. I discovered that the Security setting in InfoPath was actually set to Domain rather than Full Trust. I must have changed this for another form I was working on. Anyway, the long and short of it is that as soon as I republished my form with the Full Trust option everything jumped into life.

Very sorry to have wasted your time with this. I guess I really need to be sure that my perception of how my settings are configured actually match reality! :-( 

You've asked some good questions above that I want to address. The admin option is for a few very specific qRules commands - like SubmitAsUser, for example. There is no need to select that option unless you are going to use commands that require it. In general, I suggest always using browser / sandbox, even in a Filler form, unless you are using commands that require a different option (for a Filler form, for example, you may be wanting to use some of the options only available for Filler). I'm glad your form is now working as anticipated again - and don't feel like you need to apologize or like you wasted time. There are always a number of different settings in play.

 Hi Hilary,

I hope the original thread owner won't mind me asking this in here.

Do you have a list or documentation of rules which requires QRule Injection's Admin option? Or if I'm missing it, would you be kind enough to share the link?

Thanks in advance!

 

There are so very few commands that require the admin option - RenderForm & SubmitAsUser do, and maybe one or two more. I'll make a note to get this documented with the next release.

 Sounds awesome! Thanks again Hilary :)