views:

449

answers:

0

Environment

Microsoft Office SharePoint Server 2007 SP2 running on Windows Server 2003 R2 SP2. The MOSS server is a standalone server on a domain used for outward facing boxes. It has a one-way trust with our production domain. InfoPath 2007 SP1 is being used to author the forms.

Scenario

1) I have a web-enabled InfoPath form that I have published to Central Administration and enabled as a feature on the site collection. To simplify troubleshooting with MS support they had me make a simple form with a single text field and I still get the same behavior.

2) The InfoPath form is a content type for a forms library. The forms library is set to open the form Web Only (although switching that setting made no difference). I have created another forms library and still get the same behavior. Document libraries do not exhibit the behavior.

3) I can click New on the document library and the form is served up by InfoPath Forms Services. I can fill in the form and click Submit and it successfully gets submitted to the library.

4) An out-of-the-box SharePoint approval workflow on the forms library triggers upon that submission and I get the email from that.

5) When I then try to open the form I get an InfoPath Forms Services error: “Retrieval of the XML document from the following location is not authorized: /sites/xyz/Foo.xml.”

6) The SharePoint log shows “Forms Server Forms Services File Open 7tfu Medium User attempted to open a file they didn't have access to.” Note that the user id trying to open the form is (a) the same user id that submitted the form, and (b) has Full Control of the site and the library.

7) If I click the down-arrow on the item and choose Open in InfoPath the form opens correctly.

8) I can also delete the form from the library.

9) In addition, a similar behavior is exhibiting itself in the Tasks library where the workflow goes. If I click on the task for the workflow item generated by the form submission I get a permissions error (again, even though the id has Full Control for the site). However, I can delete the task!

10) The same error occurs whether I submit the form and then try to access it using an id on the domain the SharePoint server lives on user id or an id from the production domain.

So to recap:

1) Can submit a form to the library.

2) Cannot then reopen the form from the library using Forms Services.

3) Can open the form from the library using InfoPath.

4) Can delete the form.

5) Cannot open the workflow task associated with the form.

6) Can delete the workflow task associated with the form.

Needless to say, I am very confused about how this could occur. And so far, after two days of working on it, so is MS support. They have taken a backup of our site and imported it and cannot replicate the behavior. They are escalating the issue, but in the mean time I thought I would see if anyone else had insight because this is impacting a project that is now past due because of this issue. Any and all comments, suggestions or ideas appreciated.

Follow up:

So, I went back to some basics and have an interesting twist.

The root site collection is https://www.abc.com/sites/Root. It was where I originally developed everything. However, I really only want the root site collection to hold reference materials available across all sites that will be created – manuals and the like that we only want to update in one place. So then I created a template of that site and created a new site in the site collection at https://www.abc.com/sites/Root/Template. The purpose of this site was to serve as a template for the subsequent sites. So I got rid of everything in the Template site that is held as singletons/reference info in the Root site and kept only those items that need to be created for each unique site – specifically the forms library, a document library which will hold uploaded PDFs containing the scanned docs, an images library called Logos which will hold each site's logo, and the Tasks list that holds the Workflow tasks. When I had the Template site as I wanted it I then created a second template from it.

I then used that second template to set up the test site, https://www.abc.com/sites/Root/Test. It is on that site we’ve been doing all the testing. The only thing I then do on the Test site is to break permissions inheritance on the forms library and change it so that a specific A/D group that represents that site's users who have Contribute access to the library instead of just Read.

On a hunch this morning I went back and tested on the Root site and everything still works there – I can submit the form, open it after submission, open the workflow tasks, etc. I then went and tested on the Template site and I get the same security error we’ve been battling on the Test site. It looks like something is happening when I create that site from the root site’s template. I have even deleted and recreated the Template site and done none of the post-create work I was doing (I left everything in place from the Root site template, didn't change the forms library permissions - it should be IDENTICAL to the Root site. And it still has the same issues - I can submit the form using InfoPath Forms Services but cannot then open it nor the task that is created by the Approval workflow. Considering that the Template site inherits permissions from the Root site, and considering I have checked effective permissions and compared permissions sets using the SharePoint Administrator's Toolkit and its Permissions Reporting feature, I remain confused.