-
Oh, I see - I missed where you said this was failing in the browser only? You may want to try temporarily moving it out of the section you currently have it in - see if that nesting is what is tripping up the browser, since the section is bound to a sibling node?
-
How odd - as I said, this doesn't reproduce for me.
-
So - I modified the "lock if top management" rule (changed it to set the color of the row instead of disable) since your SharePoint data connections wouldn't be loading for me, and when I set Beforehand Cost Status to Paid, the insert / delete function was disabled. I'm sure you've verified this - but maybe check that logic ...
-
Maybe ../../../preceding-sibling::my:SharePointListItem_RW/my:Editor/pc:Person/pc:AccountId for the account ID?
-
Is this in email? Or when you open the form in Filler? Or in the browser? If in email, in the view sent in the email, this would be normal.
-
Hi, Arthur - sorry we missed this question. My guess is that you need to set postback to always on your date controls to make sure the qRules command executes - that is under the control's properties on the browser tab. Usually, when a qRules command works in Filler (Preview) but not in browser, that is the first thing to check. :)
-
I would think you just need a rule on each of the checkbox fields that runs when the field is "false" to set things back? Have you tried that? Feel free to attach your form under Options in a reply if you'd like me to take a look. :)
-
Awesome - thanks for posting! :)
-
Which table has the issue?
-
The sample form doesn't have qRules or a SharePoint list mapping. Can you attach your mapping XML file?