Beware with Unique Permissions on PublishingPages, AddAndCustomizePages and Embed Code in a page

Interesting puzzle solved: page authors complained that some of them face an issue when they try to insert a Microsoft Stream video via embed code in the page body:

The message clearly points to missing of 'AddAndCustomizePages' permission for the logged-on page author. However, on checking the permissions, all the authors / editors do have that permission via an assigned 'Content Management' permission level. After some trial-and-error, I discovered the SharePoint internal cause. The below error message on trying to insert a ScriptEditor webpart in the page content, led me to the Eureka insight:

This site says... Aha: In the site the permission inheritance is broken, to achieve that page authors can only create and modify page (= news) items, but are restricted from modifying anything else in the site. The 'Content Management' permission level is for that purpose not assigned to them on site level, but on the Pages library. On required permission for their author task this assignment is sufficient. But a flaw in SharePoint is that it checks in the 'Insert Embed-code' handling whether the 'AddAndCustomizePages' permission is granted to the logged-on author on site level.

With this insight / understanding on SharePoint level, the fix clear: make sure that all the page authors are also granted a permission level on site level that includes the 'AddAndCustomizePages' permission. And with that fix, all page authors are enabled / authorized to user-friendly apply 'Embed Code' in page edit mode:

CQWP, PictureLibrary and Blobcache

ContentByQueryWebPart is a very usable ‘tool’ to display all types of SharePoint data in a page. Listdata, document libraries and also picture library. But be aware that CQWP has some strange default behaviour wrt picture library. CQWP by default displays the preview images, instead of the actual images.

This also has several performance ramifications:

1. On server side: actual images can be cached in blobcache, but preview images and also thumbnails are by SharePoint design not cached in blobcache. The reasoning is that blobcache is for content that is multiple times (often) retrieved, while preview images are typically only of interest for content manager upon functional management of the picture library contents. As result, each request for a preview image means that SharePoint needs to retrieve it from the content database.
2. On client, network + server side: browser cache can be applied to avoid the browser over and over requesting same image. But the browser then still needs to query the server whether the cached resource is unmodified at the server (response 304). For images / static resources that do not change (often), even this request can be avoided: minimizing request/response handling between client (browser), server, and the network transfer. Browsers support this via ‘max-age’ setting. SharePoint supports this ‘max-age’ setting for SharePoint content, via… Blobcache. For SharePoint content retrieved outside blobcache, as thus preview images, the max-age value is not set in the http response. As result, the browser will query the remote SharePoint server whether the image is unmodified, and the server responds with '304 NotModified'. And this can end-up in some noticeable latency, dependent on how busy the SharePoint server is:

Solution is to modify the CQWP configuration to retrieve and display the actual image. This comprises of 2 parts:

1. In the ItemStyle.xsl, change the rendering specification to display ‘EncodedAbsUrl’ iso ‘ImageUrl’;

2. And you need to modify the ‘CommonViewFields’ specification of CQWP instance, to also include ‘EncodedAbsUrl’.

SharePoint 2010 CMIS Connector

To enable content management interoperability between different CMS repositories, the OASIS organization defined the Content Management Interoperability Standard specification. Although a.o. Microsoft played a major role in the OASIS working group defining this proposed standard, up to now it did not provide a concrete and product-ready implementation of the CMIS specification for SharePoint 2007. There is only a reference/example implementation available on MSDN, with code download.

Apparently Microsoft decided to wait with active support of the CMIS specification for the next SharePoint version. For SharePoint Server 2010 Microsoft now packages a CMIS connector as part of the Administration Toolkit v1.0. The CMIS Connector for SharePoint provides a CMIS (Content Management Interoperability Services) interface over the top of SharePoint as well as a CMIS consumer Web Part that can be used to display content from other CMIS enabled repositories. [source: Microsoft SharePoint Teamblog] Or stated otherwise: via this CMIS Connector, SharePoint Server 2010 can both function as CMIS consumer of content stored in external repositories, and as CMIS producer of content stored within SharePoint lists and libraries.

Mind you...

• the CMIS Connector is not supported for SharePoint Foundation 2010
• and there is still only limited support of the CMIS standard by other CMS vendors; the real value of CMIS requires [at least] 2 to tango...

Tip - Provision a Functional Management page for application data

One of the faces/capabilities of the SharePoint platform is that of Web/Enterprise Content Management System (WCM, ECM). When we architect and setup a WCM-enabled SharePoint (publishing) site, there are actually 2 different types of users to take into consideration:

1. The end-users browsing and using the website;
2. The content managers, who have the responsibity for maintaining the content on the website up-to-date

When designing the website, the primary focus is almost naturally on the end-users. Understandable, after all a site which does not attract and keeps the interest of end-users is in fact useless for the company. However, it certainly is also beneficial to give appropriate attention to the usage model for the content manager role. If they can do their content work in a more user-friendly and efficient manner, the site will most likely benefit from this by being more and more often kept up-to-date. Content management is a task difficult enough on the functional level, without the technical / usage model burden of SharePoint content management.

Content in a publishing website comes in various forms. Most known are of course the publishing / web pages, as the entities to which the end-user navigates. But there are more type of content-entities possible:

• downloadable documents (administered in document libraries)
• pictures displayed somewhere in the site (administered in picture libraries)
• data displayed somewhere in the site. Examples are news items, events calendar, links to related information (administered in SharePoint lists)

When the SharePoint is based on one of the publishing site templates, content management of the individual pages is already to a certain amount enabled for the site contributors. An authorized contributor can start the creation of a new page, or the modification of an existing one directly from the siteactions menu. However, if the contributor needs to change one of the other types of content (document, picture, basic list data), there is no such direct usage model. Instead one has to follow the path of Site Actions --> Site Settings --> List and Libraries --> identify and then select the appropriate list ... This is rather cumbersone, and involves a lot of mouseclicks (irritating) + the retrieval and rendering of multiple application pages before arriving at the final destination (time-costly for the user). Another disadvantage is that the content owner must self identify in the listed overview of all the SharePoint lists and libraries in the current site, the particular list/library which holds the content type.

Wouldn't it be nice to apply a comparable usage model as for page-modification to non-page content items ? I thought so, and have realized it within various SharePoint CMS-projects. The basic usage model is:

1. A contributor selects the Site Actions menu
2. The Site Actions menu is extended with a custom action for functional data management

   
3. The functional data management menu entry navigates the browser to a functional data management page. On this page the different relevant content types are enumerated in list form, with direct recognizable identifications.

   
4. Clicking on one of the content type links navigates the browser to a page on which the data items of the related list are displayed. The contributor can here manage the content of this specific type, for instance news messages.

   

This usage pattern improves the user experience for the content management role:

• The usage model for non-page content applies the same pattern as for publishing page content
• The navigation is direct, and orientated at functional level
• Lesser mouseclicks and page retrievals
• Contributor is shielded of from confrontation with the total collection of SharePoint lists and libraries in the site

At SharePoint technical level the following is done to enable this usage pattern:

1. Entry on Site Actions menu: Provision via a feature a custom action, to add an entry to the Site Actions menu, with it's action set to navigate to functional CMS management page.
2. Functional CMS Management page: Provision a web page with on it a Content Editor webpart (CWEP), and add htlm to render a list of the different content types. Each item in the list hyperlinks to the same edit page for editing the contents of the selected list. The listname is propagated via the QueryString.
3. Editable list view: Provision a second web page with on it a ListView webpart. The ListView webpart is used to display the different items in the SharePoint list or library, and to enter new item or edit existent item. This web page is reused to display the contents of the different content lists and libraries. For this it is required to runtime connect the contained ListView to a specific list or library, following the selection the content manager made from the overview. The ListView webpart itself does not exhibit QueryString behaviour. Therefore a hidden technical webpart is added to the page which parses the QueryString to detect the requested list, and next runtime push this setting onto the ListView webpart on same page.

And that's basically it. Your site's content managers will thank you for delivering this CMS functionality. At least, that has been my experience on several occassions/projects...