why do Contributors have access to edit my main page?

This issue only occurs with publishing templates. With collaboration templates, Contributors do not have any Site Actions menu choices.

Some people go off making permission levels to fix this. This will not work since Contributors still need Edit & Delete rights to the lists in the site.

This issue occurs because in sites created with the publishing template, Contributors have Add/Edit/Delete rights to the Pages document library (which is where the home page is typically stored).

The simple fix for this is:

• break the permission inheritance for the Pages doclib
  
• change the permissions for the Contributors (probably Home Members) to only allow read access
  

Although the Site Actions menu will still be present, Create Page and Edit Page will no longer show up!

Regards..

why is the Include-Content button greyed when making a list template?

Apparently this occurs when there is a Lookup-type column in the list. Just remove this column and it should be save-able (sic) with the content. Another optin is to "de-reference" the lookup column. Do this by:

- create a new text column
- go into datasheet mode
- select the entire lookup column and copy/paste into the new text column

The reason this occurs is because a lookup column works by referencing an interal generated name for the list it references.

The "instantiate a template" function cannot recreate the lookup column field (since the referred-to-list may not even exist where the new list is instantiated), so they chose to disable saving the content if this field is present.

Document conversion not very useful & broken in one case

This is another case where the Publishing parts of MOSS are not integrated cleanly IMO.

I created a site collection under a publishing root level site. This site collection did not have the Publishing Features activated.

When I uploaded a Word 2007 file, the context menu has an item labelled Convert Document >> From Word Document to Web Page.

Not knowing what this was I tried it. You immediately get an error screen displaying:

The site is not valid. The 'Pages' document library is missing.

There is no indication what the problem is related to.

So I created a 'Pages' document library. Tried the same menu item and got the same message.

Then I added the Publishing Infrastructure to my site. Same result.

Then I looked on the web about this error message and I was instructed to check Central Administration. I did this and saw:

Document Conversions Launcher Service is present and started

Finally I made a site collection using the Publishing site template. Then I uploaded the document to this new site collection and tried the menu item again. Lo and behold:

The document converter was able to create HTML from this document, but it had to modify the output:
1 embedded image(s) from the document were not preserved in the HTML.

Click OK to go to the created page.

I went to the page and it looked like Word's old SaveAs Html option. Not very useful!

So this menu item is enabled even though in many instances it will cause an error. Not the A answer!

Regards..

Roger Williams
Franklin Laboratory

copying including associated metadata

There is some good news on this issue.

Basically if you copy a document library item that is a certain content type and contains certain meta-data to another location, using ECB >> Send To >> Other Location, the entire content type will be copied providing that the destination document library has content types enabled as well as the "copied from" content type.

In my tests, if the content type management is not enabled in the docuement library, only the document gets copied and it truncates the metadata. The fact that no message is issued on loss of dat is a bug IMO.

To test this do the following steps:

• optionally create any needed site columns
  
• create a content type (using those columns)
  
• create the target document library
  
• enable content types (List Settings >> Advanced Settings >> Allow management of content types)
  
• include the source content type in the target doclib (List Settings >> Add from existing site content type)
  
• save a copy of the target document library URL
  
• go to the source document library
  
• navigate to the folder or view containing the item to copy
  
• use the Edit-Control-Block to perform the copy (ECB >> Send To >> Other Location)
  
• paste in the target document library URL (strip off Forms/AllItems.aspx)
  
• hit OK twice
  

This should do it. Note that there are several additional capabilities this should have, including:

• let the user pick the doclib from a screen
  
• let the user select folders
  
• let the user select several items to copy simulatneously
  
• the system should strip the URL for the user
  
• reduce the number of clicks!!
  

Other needed tests include:

• content type mis-match but meta-data match (using doclib list columns
  
• built-in content types and complete meta-data match
  

Anyway, at least it works for the center-of-the-street case.

Regards..

Roger Williams
Franklin Laboratory

making pages containing lists of sites, lists

One of the projects I am working on needed some pages containing lists of subsites and lists of lists. Some examples include:

• A top-level site that has lots of blog sites beneath it. The user wants a list of all of the blog sites to appear in a web part on the top level site.
  
• A top-level site that has lots of discussion boards contained within it. The user wants a list of all of the discussion boards inside this site.

Note that top-level in this case does not necessarily mean a site collection.

I could not find a built-in web part to accomplish this. However, it is very straighforward to create a DVWP (i.e. data view web part) talking to built-in WSS web services. This is done using SharePoint Designer. Here is the process:

• create a web part page (Site Actions >> Create >> Web part page)
  
• open the page in SPD (use either Design or Split view)
  
• Data View >> Manage Data Sources
  
• In the Data Source Library, select Connect to a web service
  

Here the directions will be slightly different for sites vs. lists

For Sites:

• use http://<your site>/_vti_bin/webs.asmx for sub-sites
  
• use the GetWebCollection method
  
• after creating this data source, drag it into one of the web part zones on the new page (this creates a DVWP)
  
• use the context menu ">" and season to taste
  

For Lists:

• use http://<your site>/_vti_bin/lists.asmx for containing lists
• use the GetListCollection method
  
• after creating this data source, drag it into one of the web part zones on the new page (this creates a DVWP)
  
• use the context menu ">" and season to taste
  

Good luck!

Wiki pages are not first class "items" in WSS v3

One of the strengths of the WSS platform is that all of the built-in list types have the same features set, such as alerting, permissions, folders, metadata. Not!

One of my customers is doing a Web 2.0 implementation using MOSS as the platform. They will be using the Wiki page type extensively.

Now I have recently discovered that Wiki page libraries cannot make folders for the pages.

This has the potential to be a large issue for 2 reasons:

• folders allow a better organization of the pages
  
• WSS has a well-known performance issue when a single view of data becomes longer than 2000 items

So this is definitely a drawback that will need to me mitigated. It is certainly possible that a code-based solution will be the best mitigation for this issue.

Here is a MSDN thread with the start of a workaround on this.

Note further that the Kwizcom product with enhanced Wiki capability also has this limitation.

InfoPath cannot handle URL fields in SP lists

One component of the dream of no-code SharePoint is to store data in SharePoint lists and expose the data thru Infopath [which business analysts and administrators can use to change the UI design easily].

This dream is dimmed slightly when InfoPath cannot handle SharePoint list types correctly. In this case, URL fields are not parsed correctly causing the link field to fail [when clicked].

In this example, I made a URL field in a custom list called "u 0" and I stored a value in it.

Make the infoPath form with a datasource pointing to the custom list. Then you will see the symptom of this problem. The problem itself is caused by this XSLT code stored in view1.xsl. (Sorry, I could not get the formatting to work!)

<span class="xdHyperlink" hideFocus="1" title="" style="OVERFLOW: visible; WIDTH: 130px; TEXT-ALIGN: left" xd:xctname="Hyperlink">
<a class="xdDataBindingUI" xd:CtrlId="CTRL4" tabIndex="0" xd:disableEditing="yes">
<xsl:attribute name="href">
<xsl:value-of select="@u_0"/>
</xsl:attribute>
<xsl:value-of select="@u_0"/>
</a>
</span>


The correct code is shown below:


<span class="xdHyperlink" hideFocus="1" title="" style="OVERFLOW: visible; WIDTH: 130px; TEXT-ALIGN: left" xd:xctname="Hyperlink">
<a class="xdDataBindingUI" xd:CtrlId="CTRL4" tabIndex="0" xd:disableEditing="yes">
<xsl:attribute name="href">
<xsl:value-of select="substring-before(@u_0, ',')"/>
</xsl:attribute>
<xsl:value-of select="substring-after(@u_0, ',')"/>
</a>
</span>

I find it hard to believe but apparently noone has documented this out on the web. After I debugged it, I found this link from 2005 about the SPD predecessor, of which #5 & #6 are the answer.

It is also frustrating that Microsoft has not fixed this in the InfoPath 2007 product.

Regards..