InfoPath Dev

 I'm using the document "qRules and SharePoint-Related Commands" and I'm following the instructions "How to use the SubmittoSharePointList command (pages 2-9). I've got as far as step 23 and I've been able to successfully add an entry to my SharePoint list and also modify that entry once it's been created. However, if I add an attachment to my form and submit, the attachment is not sent to SharePoint although qRules reports that the submit was executed successfully. On the screen dump that accompanies step 23 it shows a form with a file attached and the qRulesLink and qRulesFilename properties populated. These fields aren't populated in my form.

 

Step 23 states "Finally, in Preview mode, try submitting new list items by filling out the Title and the Value fields and clicking Submit. You should see that the item gets submitted to the SharePoint list it has been mapped to and returns the list item ID back in your form" I don't know what is meant by "Value fields" in this instruction but I assume it's referring to the "Information" field? Step 23 makes no mention of adding an attachment even though the screen dump clearly shows that this has been done. I'm confused. Should the submission of attachments work at this point or not? My mapping file contains entries for my:ID and my:attachments/my:attachmentsFile and my submit looks like this:

SubmitToSharePointList /submit=ShPSubmit /dsname=AddAttachment /xpath=my:attachments/my:attachmentFile /uniqueName=yes

When I created the mapping file and added the attachment field the following text appears in the SharePoint Column "The attachment field is not mapped to a SharePoint column - it is used by qRules to add attachments to your list items if you include the /dsname parameter. You must indicate an ID filed to also add attachments". What is meant by this? "Indicate an ID field" where? Does this mean that you need the ID of the list item before you can add an attachment to it - ie you can't create a new list item with an attachment in one submit - you have to first create the list item and then add an attachment to it once you know the ID?

I've tested the theory by first populating the Title and Information fields and clicking the Submit button. A list entry duly appears in the SharePoint list. I then went back to my form, modified the Title field, added an attachment and again clicked the Submit button In SharePoint I could see the Title was modified but no attachment was added to the list item. Of course it could be that I'm just too dumb to use qRules but I feel the instructions given in this example are vague and open to interpretation. :-)

Any help gratefully received. 

 

 

 

Can I see a copy of your form? You can attach it under the Options tab in a reply. It is way more likely that the instructions are the issue & you are not. :)

 Hi Hilary,

Another fast reply - this support board is awesome! :-) I've attached the form. Hopefully I haven't done something dumb.

 I've asked a colleague of mine to review the document you mention so we can either update it or clarify it.

But could you try this for your command and let's see if that gets you any further: SubmitToSharePointList /submit=ShPSubmit /dsname=AddAttachment

Your mapping file includes the attachment field, so you shouldn't need to include the /xpath parameter. In the /xpath parameter, you had: /xpath=my:attachments/my:attachmentFile but the XPath is case sensitive - and your attachments field XPath is /my:myFields/my:group1/my:group2/my:Attachments

You have already added a field in your form to store the SharePoint list item ID and mapped that in your mapping file, so you are good there. When we create a list item with an attachment in SharePoint using qRules, the code creates the list item (getting back the ID) then adds the attachment. Since in the code we populate your form's ID field, we need your mapping to contain that XPath. In older versions of qRules (before 4.2), many of these things were NOT mapped, but instead added as command parameters. So - sometimes the documentation has little crufty leftovers.  

 Yes, that has worked. Thanks for the explanation. Initially I thought that a good place to start learning would be the qRules v7.1 User Guide but I would say that this is really a guide for existing users of the product who want to see what's new - hence the investigation of some of the older documents (which over time have become misleading). Is there a recommended reading route for newbie's? I'm very aware that I'm on a 30-day learning countdown during which time I need to understand the basics of the product and then implement it in some way into our existing environment so I can build a business case for purchase and demonstrate it in action. I use InfoPath to provide web front-ends to our data in SharePoint. We have a general rule not to use code in these solutions so it looks like qRules will provide the functionality we need. The demise of InfoPath is a worry though particularly as Microsoft have been less than forthcoming about what will replace it. I just hope I'm not building solutions which will only have a short shelf-life.

Thanks again for your help. :-) 

Don't worry about the trial expiration (if that is the 30-day learning countdown you are referring to?) - you can always download another trial and re-inject, or email me via the forum, and I'll update your trial in your form, okay? qRules has a LOT of different features - maybe you can outline what you are trying to achieve and I can point you to specific commands? We also have some qRules training vids up on YouTube. :)

OK, great. That's good to know. I have various lists in SharePoint which we use to keep track of hardware and who has it, so, for example, I have a PC & Laptop list, a Monitor list, a Cell Phone list etc. All these lists have a field called Current User. With InfoPath I create front-end interfaces to interact with this data and present them as a web page using the form web-part. Once such page is a "show assets by user" report. I can enter a user name and receive a report of what assets are currently assigned to them. One problem I would like to solve is to better handle what happens when a user leaves. We currently change the Current User field to a "dummy" user account which identifies the department the leaving user worked for. This is because the department is still liable for the cost of the asset until such time as a new user takes over ownership. Unfortunately, at the moment I have to go to each individual list, search for the user and then amend each record manually to change the Current User field. I'd like to inject qRules into my "show assets by user" form and add a button called "Reassign assets to department" which when clicked would change the Current User field of each of the user's assets to the dummy "department" user. I've attached a screen dump of a sample asset report so you can see what that looks like. I think the SubmitToSharePointList qRule command might be all I need in this scenario but I'll need to work with it in my form to see how this works out. Thanks again for taking the time to help out a newbie.

You'll need to copy the data from the secondary data source into the main data source to update the existing list items - but all you need to copy in is the list item ID & the field you need to change (department). So, CopyTable or Transform, or Insert with some logic to set values will probably be needed too...

Are you guys talking about a tool that allows you to attach files to an InfoPath form, but then automatically moves those files to a SharePoint list?

We are talking about qRules (a product that I work on for Qdabra) that can be added to a form to do things that you'd usually have to write code for. One of the things it can do is copy files out of a form and off to a library or list - more here: http://www.qdabra.com/en/products/qRules.aspx

Nice! Checking it out now. thanks

A little head's up - if you are using Office 365 browser forms, this product won't work for you since Sandbox has been deprecated & you may want to check out FormsViewer instead: http://www.qdabra.com/en/products/FormsViewer.aspx

OK, after a short break I'm back to the task at hand. I've been able to successfully use the CopyTable command to get data from my SharePoint list into InfoPath (a query to my list produced 3 records which were then successfully copied to InfoPath with the CopyTable command). Yay!

I now want to change the value of the Department field for each record using InfoPath's "set a fields value" but I'm not sure how to do that. I guess I need some way of recording the number of records returned and then using it in a formula? Could you point me in the right direction there?

Finally I need to write the modified records back to SharePoint but I'm a bit confused here. I have the ID of the SharePoint list item in my table in InfoPath but I thought I would have to create a mapping file so that this field would map to the ID field in SharePoint. This doesn't seem to be possible, but how does qRules know that I want to update an existing record rather than create a new one?

As always, thanks very much for your help. 

 

In your qRules mapping, when you use the InfoPath to SharePoint list tool, you can indicate a field is an ID - have you done that? Maybe attach your mapping file to a reply so I can take a look at it. If we have the ID mapped, qRules will update when you use SubmitToSharePointList if the ID has a valid value. :) As to setting the department field for each record - will you need to change all of them to the same thing? If so, if you put the rule on something outside of the repeating table / section (so the context is OUTSIDE of the repeating node) you can use set a fields value to set all of them to the same thing. If not, you'll need to use qRules SetValue command so you can indicate which you want to set using an XPath filter, OR you can just change each one by displaying your repeating data on the form.... make sense?

 Hi Hilary,

I would say your explanation was spot on. I have now been able to successfully retrieve data from a SharePoint list, modify certain fields in InfoPath and then write the records back to SharePoint. In other words - success! I'm sold on qRules and I haven't even looked at the other things it can do yet. Now I just need to smarten up my form and demonstrate it in action, but I'm pretty confident we are going to purchase this product. :-)

Thanks for being so patient and taking the time to answer questions you've probably heard a million times before. It's very rare these days to receive such high quality support (and for free). Respect!