Archive for April 2012
SharePoint 2010 Users Cannot Check Out Documents With IE
Users Cannot Checkout Documents
There have been some occurrences of some users not being able to check out documents in a document library while other users are able to do so despite both having appropriate permissions and no other normal blocking situation existing. All of the mechanisms and workflows that have allowed some users to checkout and others to not be allowed are not fully known but the message that will be seen is shown in Image 1 that follows.
This document could not be checked out. You may not have permission to check out the document or it is already checked out or locked for editing by another user.
Image 1
Symptoms Experienced:
-
Using Internet Explorer the user cannot check out some or any files from a document library
-
Using Firefox or Chrome the user can check out the files from the document library
-
User receives the message shown in Image 1 when trying to check out
-
Other users may or may not be able to check out files using different mechanisms
-
The afflicted user(s) may or may not be able to check out files using a different mechanism
Discovered Resolutions:
-
Ensure the web application has a root site collection. See KB2625462
In the one experience the creation of a root site collection for the web app resolved the issue without further action but it is suspected that in some instances the root site collection may not be sufficient or that the root site collection may already exist thus not being the sole cause for the denied check out.
It is recommended that in the absence of the root site collection existence resolving the issue or in addition the root site collection that the SharePoint OpenDocument Class add-on within Internet Explorer be investigated for the proper version. To get to the Manage add-ons screen in IE click the "cog" icon in the upper right corner to get the needed menu. See Image 2.
Image 2
Once the Manage add-ons screen has appeared look for the SharePoint OpenDocuments Class entry and if present select it. In the lower part of the window the version will appear. See Image 3.
Image 3
If Office 2010 is installed it should show the version as 14.
If it shows Version 14 and Office 2010 is installed and the user cannot check out items after the root collection exists then perform a repair on Microsoft Office.
If it shows Version 14 and Office 2010 is installed and the user can check out items then all is good.
If Office 2010 is installed and it shows a version lower than 14 then update the add-on as indicated in the next section.
If Office 2007 is installed and it shows a version lower than 14 and the user cannot check out items after the root collection exists then perform a repair on Microsoft Office.
If Office 2007 is installed and it shows a version lower than 14 and the user can check out items then all is good.
Updating the add-on
Close the Manage Add-ons window in IE if open and close all IE sessions.
Open up a console window with Administrator privileges. Change to the following directory:
C:\Program Files\Microsoft Office\Office14
run regsvr32.exe OWSSUPP.DLL
Restart IE and check the SharePoint OpenDocuments Class Add-on to see if it is version 14.
Dev 11 TFS and Potential Limits on the Requirements Category
04/24/2012 Update: I noticed that in the Microsoft Scrum V2 Template in Dev 11 that the Product Backlog Screen has two options for PBIs – Bug and Product Backlog Item. So multiple selections are an options. Now I must dig deeper to find out why it works in Scrum V2 but not MSF Agile V6. See the image that follows:
This post is pertaining to Dev 11 TFS and the use of work item categories. Not sure if this is a bug or by design. You can vote, comment or do otherwise on this reported issue on Microsoft Connect: ID 736750.
In the Agile V6 Template the Web Interface specifically the portion for presenting the burn down chart and also for working with the backlog to include adding items into the backlog, natively uses the User Story as the primary product backlog item. This use of User Story is to be expected and it seems the system uses the User Story in the roles for this portion of the web interface and many other parts of the system based on the category assignment of User Story in the Requirements Category. Nothing really new there.
The issue is that if one adds an additional work item type to the team project - a requirement work item type in this particular case and then adds that requirement work item type to the Requirements Category the system will present exception text in the web interface in place of numerous parts of the system including on the backlog management page. This is despite that the User Story type was left as the default for the Requirements Category.
It is understandable that the system might rely on the user story as the ruling product backlog item and expect it to be the default work item type for the category as it seems it is only currently able to show one work item type on the backlog screen for adding items into the backlog on the fly. But to not support additional work item types in the Requirements Category without rendering a chunk of the web interface broken is hopefully a bug versus a choice. You can see the results when adding an additional work item type in Image 1. In Image 2 is how it would look normally.
Image 1 (Click image for larger view)
Image 2 (Click image for a larger view)
The Categories.xml file with the additional work item type loads fine into the Team Project as it conforms with the schema but the results of doing so can be seen.
I know many organizations that do not use the User Story as the definitive carrier of requirements but add back into their set of work items under Agile a Requirements work item that can augment a user story or for non-functional requirements work in place of the user story (though estimated etc. in the same way)
I propose that at the least the parts in the Agile template that rely on the Requirements Category should use the DefaultWorkItemType and ideally should be able to use all item types in the Requirements Category in many instances.
There are other reasons why this might be failing.
I intend to investigate this further to see if I can rule out some other potential causes and will report back. Perhaps it is not that two types are in the category but that I have missing from my Requirements Work Item Type some estimation field or a needed set of specific States. I will look into this further but I suspect the mere existence of two work item types in the category presents the problem based on the fact that the User Story Creation section on the backlog page issues an error. It seems the page is designed to look at the Requirements Category but is not designed to know what to do if more than one entry exists.
I’ll report back as I get the opportunity.
Those Pesky SfTS Link Types and the TFS Integration Platform
Recently I was performing an TFS to TFS Work Item Migration in which the source Team Project had been originally created with version 2.x of Scrum for Team System on TFS 2008 then upgraded to TFS 2010. Not long after moving to the Team Project to TFS 2010 (or at the time of moving it) it was effectively stripped of the reliance on Scrum for Team System in that the TFS 2010 environment didn’t have a version installed and all the work items moved to use of the TFS 2010 link types built into the system.
As I was migrating the work items over to a test Team Project that was based on the Microsoft Scrum V1 template I noticed that I was not getting the links between work items as expected. I double checked and all the relationships I could see looked like the standard link types. It should just work.
Being familiar (though a little forgetful) with Willy-Peter Schaub’s post on just this sort of issue I decided it wouldn’t hurt to add in the code for link mappings:
1: <LinkTypeMapping
2: ...
3: LeftLinkType="Scrum.ImplementedBy"
4: ...
5: RightLinkType="Microsoft.TeamFoundation.Migration.TFS.LinkType.WorkItemToWorkItem"
6: />
My links then began to appear. I would imagine that it was the historical links that was causing the problems. Either that or somewhere current there still sat some reference to the Scrum.ImplementedBy.
The lesson being that even if the Scrum for Team System link is only in the history it will still prevent the present links from migrating. At least I think that is the lesson. Without digging deeper and looking at the work items now and historically I can’t be certain. I’ll report back if I decide to confirm that all present links were standard and it was only the history that presented the problem.
if !blogClogged 