In InfoPath 2010, when adding a form field to be available as a column on the SharePoint form library (File >> Advanced Form Options >> Property Promotion >> Add), the option to make the field editable from the library is missing. Instead of a checkbox with the message “Allow users to edit data in this field by using a datasheet or properties page”, there is a message “Some options are hidden when publishing to SharePoint Portal Server 2003.”
The solution is pretty simple. Re-publish the form (File >> Publish >> SharePoint Server (Publish form to a SharePoint library). Do not use Quick Publish!). As you go through the Publishing wizard, keep the selections the same to update your published file. The fourth screen will look identical to the Property Promotion dialog, but when you click Add (or Modify), the option to “Allow users to edit data in this field by using a datasheet or properties page” will be there.
On July 25th, I’ll be presenting InfoPath and SharePoint: Business Partners at the San Antonio SharePoint User Group meeting.
Capturing business data with InfoPath and SharePoint can be a powerful way to help your company to automate business processes. If you are considering using InfoPath and need some guidance on what you can do with InfoPath, or you have begun to use it but have been confounded by some of InfoPath’s limitations, this session is for you.Jim Adcock will be demonstrating how to use InfoPath and SharePoint together to fulfill real-world business requirements to automate business processes and capture critical data.
I hope to see you there!
SharePoint lists come pre-equipped with a unique naming convention for each list item. The unique ID on any SharePoint is a GUID, a “Globally Unique ID”, which identifies the item as unique from anything else in the system. (Lists also have GUIDs, as do Sites, Views, Workflows… everything has its own GUID, which is how SharePoint identifies all of its pieces. It is also why workflows built-in SharePoint Designer aren’t portable – when its start is triggered by the updating of an item in a list, it is actually triggered by the update of an item in the list with the GUID that was specified on creation. But I digress…)
The problem with GUIDs is that, in order to be truly unique, they are long and not really human-readable (nor are they intended to be).
I recently had a requirement to create a unique ID auto-incrementing for items in a list, in a particular format. (In this case it was the ListNameAbbreviationYear-IDNumber, for example LNA2010-0001, LNA2010-0001, LNA2010-0002, LNA2010-0003, etc.).
My articles, “Publish an InfoPath Form to Multiple SharePoint Sites” and its no-code companion, “A No-Code Solution to Host an InfoPath Form in Multiple SharePoint Sites”, have generated a lot more traffic than just about any other post I’ve made (excepting my post about a minor tweak for IE8).
Looking at the search traffic on my WordPress dashboard, I can get a picture of the kinds of things people are searching for and the information they are lacking when they click to my articles. This post is a response to your queries, and hopefully will answer some of your questions.
I’m going to start with some really basic information, and we’ll move quickly up to more complicated ideas. If you have some idea about InfoPath already, stick with me, because I think you will get some meaty info pretty quickly.
Of course, by far the easiest way to populate a list of states in an InfoPath form would be using an existing SharePoint list or a web service (see addendum at the end of this post).
But suppose you need to create a list of states and such a list or service doesn’t exist internally, or an external service cannot be used because of compliance issues, or there are potential access issues with a stand-alone form. Not a very broad use-case, but it could happen. (I know it can, because I ran into it…)
There are a couple of ways to generate the list.
(Updated! See the comments…)
In addition to my method of using an Event Handler to make it possible to host an InfoPath file in multiple locations, I have figured out a way to host an InfoPath form in multiple locations and be able to transfer form data from one location to the other and be able to open the forms on each site, without writing a single line of code. There is some risk involved with this process, and if the form is long there will be quite a bit of configuration work to make it go, but otherwise the solution is pretty simple.
Taking a break from talking about the merely difficult, I want to talk about doing the impossible.
“If you’ve done six impossible things this morning, why not round it off with breakfast at Milliways—the Restaurant at the End of the Universe!” – The Restaurant at the End of the Universe, by Douglas Adams
By design, InfoPath will only let you publish a form to one SharePoint location. Or, rather, to be specific, when you have published a form template to a SharePoint library, if you fill out the form, that data file will only point back to the library from which it was created to get its form template. The reason behind this is to provide a central location for the form template to reside. When a user opens the form, the layout of the form and its beahvior is determined by the template. If InfoPath can’t reach the template location, the form will not open and you will get an error:
“InfoPath cannot open the following file:
<(serverlocation)filename.xml>. The following form template for the form cannot be found: http://SharePoint/Site/List/Forms/template.xsn”
So, let’s say, for the sake of argument, that you have a requirement that the form needs to be able to be opened from two different locations that can’t talk to one another?