InfoPath Dev

Hi All,

I need a clarification on the use of Refresh Sharepoint List Items, qRules 4.3 licensed, SP 2010 Server Ent + IP 2010:

1. Does adding the qRulesLastModified attribute, added to the ID node for the destination list (on the Main DS), require a re-map of the existing mapping used with Submit To Sharepoint List? It already has the ID field and everything else.

     Note: It was not needed before as the submission with Submit To SharePoint List was only used to create Task Action Items, which are only pulled back via 2DS, but not stored on the Document(Form Library Form, browser-compatible). existing mapping seems to work, without update after adding the attribute.

2. Report mode vs Update Mode: Will using Report Mode prevent updating of the SP List with details from form, under any circumstances?

Our business logic for the particular cases requires, that the Document/Form is the primary source for data, thus the Form XML should never be modified (by a Mode=Update), even in cases when the 2DS Sharepoint List items might have been deleted or updated (stored from the same repeating table used with Submit To SharePoint List). Permissions and additional security settings are in place to prevent such cases, but as this "analysis list" is controlled by a separate department, we must ensure that the updates(Refresh Sharepoint List Items) are always one-directional ->from Form XML to the SP List containing details from the repeating table.

 Hi-

From the description of your scenario, it seems like RefreshSharePointListItems is not needed at all.

For example, let's say a user fills out a form and submits, and the list item is created. Then a user modifies the list item in the list. The next time the form is opened, it will still contain the original data and if the form is resubmitted, the existing list item should be updated (assuming the mapping includes an ID column).

You could use RefreshSharePointListItems in Report mode to tell the form user that a list item has been modified and no change will take place in the list. So I guess for information purposes you could use the command, but otherwise, if you wish to keep the InfoPath form as the gatekeeper of the latest information, then do not call RefreshSharePointListItems using Update mode, since this will read from the SharePoint list and update the form's repeating table.

Hi Ernesto,

It may not seem obvious from my previous post, but the Form XML allows the user to delete repeating table rows, which in turn have to be deleted from the destination SP List. That particular piece (deletion) did not work without the attribute on the ID field.

Another advantage is that the Form user knows, that something is incorrect/modified, so he/she can take action and enforce changes a.k.a submit updates as the Form has one-directional "overwrite" authority/priority over the SP list.

I am also curious whether there is an easy way to get only the IDs of the modified (2DS) rows. If I want to highlight the rows or cells with modified data I have to place a formatting rule on each repeating table field to match vs the 2DS "refresh" list.

Any insight would be helpful. 

 Hi - Refresh with the mode of Report will only let you know if there are diffs and create a list of data to allow qRules to know what to delete the next time you submit (if you have deleted items from the XML). Adding the qRulesLastModified attribute won't require you to remap anything.

The results node in the QdabraRules data source returns the numbers of the items that don't match. You'd want to copy that into another field, in case any additional qRules commands overwrite that value. You could leverage conditional formatting that checks to see whether the results contain your item ID - I'd use something like this:

concat("Item ", ID, " does not match.")

For the comparison - that way you can make sure you aren't getting a false match (i.e. - your form has an ID of one, but item 13 doesn't match.) You could also surface that value in the Results node to the users.

Thank you Hilary,

I was thinking to use "delimited list" as I think the "result" returns a simplified repeating list, but was not sure whether the result's formatting is changing with the type of modifications.

If I understand correctly the standard behavior  of RefreshSharepointList using the attribute is to check only for difference of date modified.

How about if the data in the destination SP list was just overwritten my another UI outside the IP Form, without actualy changing any values, except Modified and ModifiedBy metadata?

 The result node in the QdabraRules data source will contain a string with a little sentence like this:

Item 89 does not match.

For each non matching item. The comparison is done only based on the qRulesLastModified attribute as compared to the last modified date time in the list. If no values in the list item were changed except the metadata, the command would still consider it to not match - so perhaps you are best off using your current approach of comparing each field.

I need to re-open this topic as another potential issue came up, specifically "Value does not fall within the expected range".

The web-compatible form was published to SP 2010 (Server Ent) and working properly, adding/editing/deleting repeating table rows and saving the form and the repeating table to a SP list with Submit To Sharepoint List and Refresh Sharepoint List Items (Report mode only).

A wrinkle: A problem with deleting/updating after delete ("Value does not fall within the expected range" ) 

While when the form is opened in Infopath filler (the client app) from the SP Form library there were no problem, however

when the form is opened in the browser (IE) several issues started appearing:

1. On Insert row, where the table was originally empty (no rows, deleted by qRules Delete), the new rows were not shown  after being added to the end.

That was remedied by explicitly stating for the add/remove controls' properties, to "ALWAYS send data to server, when button is clicked". it was either that or adding a rule to switch the view to the same/current one.

2. On a existing form, which was already edited either with IP filler or in browser and saved properly: If the same form is opened again and a row is deleted, the browser shows the error "Value does not fall within the expected range".

The actual data, as corrected/edited before the submission has been successfully saved to the SP list via Submit To Sharepoint List. It seems as the Refresh Sharepoint List Items is returning the error and does not allow saving of the form itself.

The saving operation is tiered and first tries to save to the SP List and if no errors are found, then saves the main form.  Once the glitch appears, the form could no longer be saved properly via browser.

However, if the same form is opened in IP Filler (yes, it shows now the discrepancy, a missing item from SP list and a mismatch for the other rows which were not deleted) it does complain about the discrepancy, but if the rows from the form, which correspond to already deleted from the list are deleted manually, then the form could be saved. Loading again in either browser or IP Filler client shows no more mismatch. If after the glitch, the form is closed without able to save and opened again, the mismatch errors are shown, but the mentioned above correction with deleting the "missing from SP list rows" no longer helps to save the form or save the latest update to SP list.

I feel confused as I have no idea which "value" the error is addressing. Visually all IDs and field values are within expected ranges/types.

Any insight would be helpful.

 Hi - since the form is working in filler correctly, one thing you can try is to set (via a rule) the "useWebServices" node in the QdabraRules data source (should be in the Form folder) to "true". This will force the form to use the same code in the browser that it does in the filler. I'll file a case in our bug tracking system to see if we can reproduce your issue in our environment.

Thank you Hilary,

Appreciate it and I will try your suggestion.

More Info: The RefreshSharepointListItems is set to run on Finished Loading=TRUE

Any more-detailed hints as to when such a message (Value does not fall within the expected range) is intended to appear? Which of the two mappings associated with the command (refresh SpListItems) /dsname  or /mapping might be related to the message. I am assuming, that the exception handling messages actually differ in the qRules code.

I am guessing here, but:  Could blank fields be an issue here? Infopath Filler understanding blanks as zeroes for numerical field types, while browser does not? The blanks fields are set as not required (form and SP list, both) and the business logic dictates, those should be left blank if the user has made particular choices on the form

 I don't understand what you are saying here:

Den12:

Which of the two mappings associated with the command (refresh SpListItems) /dsname  or /mapping might be related to the message.

Do you have more than one mapping you are refreshing? /dsname is a parameter - /mapping is a parameter.

When you see this error in the browser, is it an error in the qRules error node? Or an error from the site? Can you post a screenshot under the options tab?

Yes it shows as error on the qRules node.

.. and apologies for the confusion.

Here is what I have to run on the qRules node finishedLoading=True: the rule is below, inside [ ... ].

[RefreshSharePointListItems /dsname=RefreshDefectDetails /mapping=mapping_defectdetails]

I meant that both parameters are defined as secondary connections.

The one used with dsname does Not have data retrieval on opening.

The one used with /mapping does have data retrieval on form opening.

 Thanks, that makes more sense now. The error message of Value does not fall within expected range is likely an error being returned from SharePoint that qRules is surfacing. I'd like to see your actual form - if you could mail it to Support AT Qdabra DOT com and include a link to this thread, I'd appreciate it. Please try your form w/ useWebServices set to true and see if that resolves the issue in the browser for you, as it may be a few days before I have a chance to review your form and try to reproduce this.

.. updated with better picture

trying a smaller picture,

On the left: Just after successful save/delete from IP Filler (link from browser, opened in client).

On the right: attempted delete in browser. Errors shown. The update to the SP list was successful (I verified on the list itself, not just the visual update shown on the form/screenshot), deleted the middle row and updated the other two. The form itself was not saved as it verifies the result from the previous post to SP list and stops further saving, which I am re-thinking.