-
So, just to be painfully clear here - in qRules, one of the things we can map is the actual item ID (the SharePoint List Item ID - an auto incrementing integer that every single list or library item has, whether displayed in the view or not). For updating list items, qRules uses this ID to know what to update. The mapping for the field can look ...
-
I just verified that I can use qRules SubmitToSharePoint list to update a column for an existing item in a form library - as long as the promoted property is set to allow editing from the library.
As mentioned above - the challenging thing is just that you'll need to manually modify your mapping file - and then have logic in your form to set ...
-
InfoPath leverages IE for a number of things, so yes. In fact, where I recall seeing this was in a client form - do you know if the other users trying the form are using IE 8?
-
You are using absolute XPaths instead of relative. Try this, for example:
string field1 = rows.Current.SelectSingleNode("my:field2", NamespaceManager).Value;
-
So, the error indicates that the issue may be with rich text - is this something you can work around? Or can you take a look at the entries in that list and get an idea for which one may be causing the issue (i.e. - you weren't having a problem last week, you are this week - what list items have been added or modified between now and then?)
-
The error mentions an issue with XML and has a little something about rich text. So, I'm wondering about data connections like TAGS Book, which has a rich text field - tagNotes. Can you take a copy of your form, and temporarily disable data connections on load that have XHTML fields like tagNotes? I'm headed offline for the day, but ...
-
Do you have any data connections executing on load in your form? Can you either attach your form to a reply (under options) or email to Support AT Qdabra DOT com and reference this thread? I'm not sure what is going wrong either, but it seems that maybe a data adapter to a list is part of the problem? We might be able to narrow the issue down ...
-
I usually cause the form to fail (in your case, it sounds like just opening it does that) then check the most recent log file. I start at the bottom and search up, looking for the name of my form. I have just found that sometimes I can find the issue in the logs even when there isn't a correlation ID. I know they are painful to read....
-
Are you using Office 365? Or is this your SharePoint server? If it is a server you can access the logs on, trigger the error by trying to open the form and check the log files - default locations here.
-
I usually then go to File > Save As and save a copy. From that point, I use Publish > Export source files to resave the source files in the folder I started in. There is a reference in the manifest to where the form has been saved which can cause this....