Wednesday, April 09, 2014

Users able to open documents using links, even without permissions

Recently I had to troubleshoot an issue where end-users were able to open links to documents they had no permissions to open. If they tried opening the library they got the "access denied" message that is expected, but clicking a link directly to a document in the library resulted in the document either opening up in the browser, or downloaded. We double checked the documents did not have item level security, and they didn't.

What a puzzle!

Turns out that those libraries were provisioned by code, and the code set a property on the library called "AllowEveryoneViewItems" (msdn documentation). This property, when set to true, means that anyone- even unauthenticated users, will be able to download and view items in the list or library - even without permissions.

The reason to turn it to true is when dealing with anonymous sites - for example, if you have an internet site and you want to put links to documents from pages, but you don't want users to be able to browse the library itself.

Wednesday, June 19, 2013

SharePoint 2013 Book is ready to purchase

If you are looking for a sharepoint 2013 end-user specific book, look no further

Monday, May 20, 2013

Activating the Document ID feature by code causes document sets welcome pages to show each web part twice

This is a weird one - I have a feature, that when activated loops over a list of other features and activates them - using "Force" :

site.Features.Add(currentFeatureID, true);


This works fine on most sites, but in Document Center sites, where the document ID feature is already activated document sets in the site suddenly show the web parts on the welcome page twice. I debugged it, and it turns out that this happens when the document ID feature is the culprit. However, this doesn't happen if I activate the ID feature using powershell.


My only solution at the moment is to check if the feature is already activated before activating it. This stopped the problem, but doesn't explain it.

Sunday, May 19, 2013

Finding if a site column exists in a site, by ID

Scenario - you have an ID of a site column (SPField belonging to SPWeb)and you want to find out if there is a field by that ID in the collection.


Problem: if you try something like:


web.Fields[fieldID] == null




The result is an exception if the field doesnt exist. What a shame.

The solution is to use the Contains method of the Fields collection:


web.Fields.Contains(fieldID)


*Thanks Ofer Gal for pointing this out.

Thursday, February 21, 2013

Fields not sortable or filterable

A client alarmed me today, showing me that in one document library a field I created didn't allow users to filter or sort on it. I couldn't find why in that library it did that, while the same site column in all other libraries allowed filtering and sorting. Checking in sharepoint manager showed no difference between the field in the different libraries - so I was stuck on that one as well.

After a while it dawned on me - the difference between the libraries was that in the one that was misbehaving the column was specified as a key filter - to help users filter and sort on it from the metadata navigation panel. This disabled the sort and filter in the list view.

Learn something new everyday = high blood pressure for the rest of your life.

Sunday, January 13, 2013

Folder sorting in views

A client has alerted me to an unexpected behavior of list views where folders are involved.
The client wanted to make sure the folders are always on the top of the view, regardless of sort order, and, looking at the settings of the view it should have happened. However, seemingly at random some document libraries stopped doing that, while other libraries were fine.
After digging into it a bit, I realised what the issue is: enabling and disabling folders.

You see, the client had custom folder content types added to some of the document libraries, and in those libraries the client wanted to make sure the users don't create folders of the built-in content type using the "New Folder" button in the ribbon. To achieve this, they changed the setting in document library advanced settings to not "Make "New Folder" command available?".
Turns out that when this setting is set to "no", there are other ramifications than just not showing the new folder command. It also tells views to behave as it there are no folders - and treat all folders items. Result - in those libraries folders were sorted with items, and were not at the top of the views. Makes sense if you consider that that setting is mapped to the SPList.
EnableFolderCreation
in code - meaning it tells the list that folders are not available - even though you can still create folder using the "new" button and choose a content type that inherits from folder.
To resolve this, we made sure the "Make "New Folder" command available?" option is always set to "yes", but we activated a feature that disabled the new folder button itself - not touching the document library setting.

Sunday, January 06, 2013

SharePoint error 0x81020030 Invalid file name

If you try to upload a file to a sharepoint document library, and get an error about invalid file name or url, it could be that your problem has nothing to do with the file name - it could be a problem with a corrupt column that has been added to the document library.

In my case, I had to remove column by column until I found that the issue goes away if I remove a calculated column that I created using a feature (using CAML), and the XML definition of the column was missing a critical attribute - the ResultType attribue. Adding that attribute to my XML solved the problem.

Thursday, November 15, 2012

Getting the full name of a feature by code

When you use the SPFeatureDefinition object, and you want to get the name of the feature you are manipulating, the "DisplayName" property of that object returns a string that is NOT the display name of the feature as you see it when you view the feature list on the site. For example, the display name of "Publishing Infrastructure" feature will be returned as "PublishingSite".

The reason is that the feature list is showing a localized version of the display name - so depending on the language of the site, the name of the feature displayed will be different than the display name the object exposes.

So, how to get the full display name? the SPFeatureDefinition object has a function called "GetTitle", which, when specifying a language, will return the full name of the feature. The following code sample loops over all features installed in the local farm, and using the English locale:

 foreach (SPFeatureDefinition def in SPFarm.Local.FeatureDefinitions)
                    {
                        CultureInfo locale = CultureInfo.CreateSpecificCulture("en-US");   
                                                if (def.Hidden)
                            continue;
                        Console.WriteLine(def.GetTitle(locale) + ":" + def.Id.ToString());
                        }

Wednesday, September 05, 2012

Repeated authentication prompts from SharePoint

In the past few weeks I had two clients with a similar issue - both had some users expiriencing multiple requests for user name and password whenever they accessed the site. With one client entering the user name and password sometimes worked, and sometimes would request 10 times and then show the site, and sometimes would just result in a blank, empty page. With the other client, they would always get to a "internet explorer cannot display the web page" error page.

If you research the issue on your favorite search engine, you will find a lot of references to authentication providers (forms, claims and so on), registry issues, trusted sites or intranet zone settings or maybe the users are on the server and the loopback check was not disabled. Well, none of these were valid in the case of these two clients - for one thing, the users were not on the server - they were on their desktops. For another thing - even when the site was added to trusted sites it still happened. Most perpelxingly - with one client it only happenned to users on windows XP, not the users who were on Windows7...

After wasting a lot of time troublshooting the issue, I finally realised what must be different between those users and the rest, and why it sometimes worked and sometimes it didn't - it was the proxy server!

Turns out both clients had a proxy server, with proxy settings deployed to desktops via group policy. The proxy would behave differently every time it was asked for the new web site address, and would cause an authentication prompt for each image on the page. In one organisation, the proxy settings that were deployed were different for Windows XP users - which explains why only those users expirienced the issues.

The solution? I told the network admins to either add the web site to the proxy exception list in IE (via group policy) or fix the proxy server itself.

Tuesday, August 28, 2012

Setting a default to the site collection administrator value

If you are like me, you may find yourself constantly creating site collections manually to test and retest something or other, and scripting the site collection creation doesnt always make sense - depending on what you are testing.

Today I got tired of entering the user name over and over again in the site collection administrator box - it is always the name of my user - which is the only user in my domain as it is a stand along development box. So...I hacked the page for site collection so it would have a default and I won't have to worry about it. Note that this should only be done in development boxes, and at your own risk.

My solution was to edit the built-in "createsite.aspx" file, sitting at "C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\14\TEMPLATE\ADMIN\createsite.aspx". In that file I located the "PeopleEditor" control with ID "PickerOwner" and added CommaSeparatedAccounts="mydomain\ishai". Save, and done!