Browser enabled form MOSS library multiple version issue

[jon]

I was really suprised to not find more on this issue from scouring the
forums. I have a couple questions about handling browser enabled forms in a
MOSS library.

If I have a library with an administrator approved form template approved to
it as a content type with a version of 1.0, everything is happy. Users can
open filled out forms in their browser, make changes, etc.

Now, lets say I want to add a new field to the template. My designers add
the field to the template, and publish it to be approved by the
administrator. Now, when I manage the content type in central
administration, I'm incrementing the version by 1. I then add the new
content type to the library, and when users click "new", they get version 2
opening in the browser.

The problem comes when they open a version 1.0 form. Now they can no longer
open the form in the browser, and must instead use the infopath client.

Am I going through this process wrong, or is there a way to make this work?
I guess I'm not sure if when I'm "changing" a form template that has already
been approved if it should have the same name when published to be approved
as the prior version (or if that even matters), and then the process behind
how to get multiple versions to all be browser enabled in one library isn't
clicking.

Any ideas?

 

[Gavin McKay]

Hi Jon,

That sounds strange - normally when you upgrade a form in an InfoPath form
library it should also upgrade the Xml, so that it can still be opened in the
browser. Do your users get some sort of error message saying why they can't
open the form in their browser?

One way this could happen is if the new version of the form cannot be
upgraded by InfoPath i.e. too many complex changes in the Xml (like deleting
nodes in the data source). In that case you need to manually update the Xml
files in the forms library. You would need to write a utility to fix this.

Gavin.

 

[jon]

I guess that's the wierd part. In this example, all I did was add a new field.

My suspicion is that the issue is versioning and content types. Can someone
give me a high level overview of the process for changing a form template
properly / versioning once it's already been published? (an administrator
approved template)

My assumption is:
1) Form designer has copy saved locally, they publish to my library.
They're forced by the wizard to save the form to be approved. (we save them
to a network share)
2) The MOSS administrator approves the template in central administration,
and activates it to a site collection.
3) Someone with appropriate permissions makes the approved content type the
"default" content type in the doc/form library, and sets the option to render
in browser
-At this point, we have v1 of the form running. Next:
4.) To change the template (say, add a field), we can either a) open the
template on the network share and make changes, then re-publish (using the
same name), and go through the approval process again to properly version the
form, or b) do the same thing, but do it by opening the "pre-published"
(locally saved) copy of the form, overwriting the template on the network
share when publishing.

Is this right? If this is done properly, changes to a form should not
require any changes in the doc/form library, right? (because there's only one
content type there).

I suspect our issues arose when we published v2 of the form, but gave it a
new name (thus making it a new content type available in the library).

Gavin, to answer your question, they don't get an error, they are just
prompted to open the form in infopath (client)...which works fine if they
have infopath installed.

 

[Gavin McKay]

Hi Jon,

Ah OK, your assumption is correct - if you change the name of your form and
then add it to MOSS/Forms Services, then it is assumed that this is a *new*
form and not an updated version of your previous form. If you want to
maintain the same content type and allow previous versions of your form data
to be upgraded automatically when opened, then you need to maintain the same
form name. The versioning process will (in most cases) take care of the rest.

There are two possible options I can think of if you want to get the form to
always open in the browser instead of trying to open the InfoPath client:

1. Ensure that MOSS/Form Services are configured to foce browser-enabled
forms to open in the browser:

http://enterprise-solutions.swits.n...orce-browser-enabled-form-open-in-browser.htm

2. Create a link to your form and include parameters to force the form into
your browser:

http://msdn2.microsoft.com/en-us/library/ms772417.aspx

Usually the first option should work fine, but sometimes I've needed to use
the second option as well.

HTH

Gavin.

 

[jon]

Gavin,
Thanks for the help! Perhaps a couple final points you could clarify for me?

1.) Lets say that I don't have the "pre-published" template anymore (local
copy). In this situation, I would assume that it's OK to take the template
right out of the libraries \Forms directory, save it locally, make my
changes, and publish the new version through the admin approve process.

2.) We use lots of drop down fields in our forms that link back to common
lists (which are SharePoint lists). This keep us from having to involve form
designers when the drop down values need to change. I noticed (just today)
that I can convert this data source to a .udcx. I get how that works, but am
wondering if one approach is better than the other? (I can see the benefit
if you're working with data that isn't stored directly in a sharepoint list,
just not sure if there would be a benefit in our case)

Any more questions, I promise I'll start a new post! Figured it would be
easier for you to answer these knowing the background I'm coming from with
this library.

 

[Gavin McKay]

Hi Jon,

1. Yes that should be OK. You need to track down the forms location in
Sharepoint which you can find by opening the form Xml. There should be a
direct reference to the template there so you can navigate to the location by
hacking the URL.

2. I convert all our form data sources to .udcx files for one main reason -
if you are moving templates between servers you can just move the .udcx files
and update them as required to point to different locations.

For example, lets say you have a dev/test/prod server. If you have the data
sources living in InfoPath then moving between servers means you have to
update each individual data source to point it to the different servers.
Which hurts By using a referenced .udcx file, you can edit the files
themselves (they are just small xml files) to point them to different
servers, and then you don't have to mess with them after that.

There are other benefits as well i.e. caching on server, centrally managed,
permissions, publishing etc. but for me, that's the biggest advantage. It
drastically reduces deployment pain.

A form I was working on had hard-coded data connections in the form and they
were pointing to our development server for list-based data. It wasn't until
someone switched off the development server and the product infopath form
stopped working that we realised what the problem was. Ooops

Gavin.

 

[Gavin McKay]

Oh and one more really weird thing - if you are creating your own Data
Connection Library in a WSS site (might be the same for MOSS not sure...) to
host your .udcx files, some site templates don't offer the Data Connection
Library as an option when creating a library. For example, the "Blank" site
template does let you create them, but the "Team" site template doesn't offer
the template at all. This was about May 2007 so my memory is a bit hazy on
the details...