[Anonymous]

Just FYI: the issue does not apply to Create. On Create, since there is no existing Content Type field on the record being created, we were not able to do the above. But Content Type is a querystring parameter on create (or, actually, the GUID of the content type). So we are using that as our filter value.

Which makes me think I might be able to do the same thing for Read and Update by changing the qListViews on the default.aspx and elsewhere to include the content type as a querystring parameter. I will try that and see how it goes.

[Anonymous]

We have an HR application that we built with heavy use of what was then called Quest Web Parts. In the application, nine different types of HR actions are supported via nine different content types (contained within a single list, sharing a common custom base content type).

One of the things we did was do build a custom page header/footer for our Create/Read/Update pages so that the right action name (New Hire, Layoff, etc.) would show. So the page layout was as follows:

LayoutExampleqListView with Custom Display 1New HireqListForm

First Name: Jane

Last Name: Doe

qListView with Custom Display 2Note: Please attach application for new hire

The top and bottom panels use the Custom Display feature of qListView to present the header and footer, which are pulled from a special list of header/footer HTML. The special list contains a column which maps to the content type. The main (middle) panel pulls from the primary HR list. The correct header and footer shows on the Read and Update pages via web part connections which depend on the Content Type column in the HR list.

In testing for our migration to SP2010, I saw that the connections appeared to have broken. In attempting to reestablish them, I discovered that the “Content Type” column is no longer provided as one of the fields to map to. I have no doubt this is ultimately a Sharepoint issue rather than a Quest one. But are there suggestions on a quick fix? Otherwise I will have to redesign how the header and footer are getting pulled in.

[Anonymous]

I was able to work around the problem but only because Quest qListView allows me to pass in the content type as a querystring parameter. Accessing the form from an OTB view would still be a problem.

[Author]

Posts