4

I've setup a custom event receiver. The purpose of my event receiver is to stop people from uploading any file type except PDF's. Right now my code looks like this:

            if (properties.AfterUrl.Substring(properties.AfterUrl.Length-4).ToLower() != ".pdf")
            {
                properties.Cancel = true;
                properties.Status = SPEventReceiverStatus.CancelWithError;
                properties.ErrorMessage = "Adding non PDF files is not allowed.";
            }

The problem is that this prevents people from adding folders, unless you make all your folder names end with .pdf :). I've considered the option of putting a check to see if the item being added contains a period, like properties.AfterUrl.Contains("."), however this would allow tricky people to upload files that have no extension and would disallow folder names with periods.

I did a comparison of SPItemEventProperties between WSS3 and 2010 and found that they added a property called FileSystemObjectTypePropertyName, my guess is that in 2010 this property fills the roll. For the time being though I am stuck with WSS3.

Thoughts?

Improve this question
5

You might be able to differentiate by knowing Content Type of the item being added. You can get Content Type by accessing properties.AfterProperties["ContentTypeId"]

As documented here, Document Content Type ID starts with 0x0101 vs Folder's content type id - 0x0120

So your code may look like:

SPContentTypeId itemContentType = new SPContentTypeId(properties.AfterProperties["ContentTypeId"]);

SPContentTypeId folderContentType = SPBuiltInContentTypeId.Folder;

if (!itemContentType.IsChildOf(folderContentType))

{

// this should be a document not a folder

}

Improve this answer
7
  • ContentType is not present. ContenTypeId is present when I use the web interface (properties.AfterProperties["ContentTypeId"]) but not when I use the Windows Explorer interface. ContentTypeId appears to be a guid. – Peter Nov 16 '11 at 17:35
  • Just saw your update. I do think that throught the web interface this would solve the issue, now I'm just worried about people going through Explorer view. – Peter Nov 16 '11 at 17:38
  • can you share the examples of value you are getting when usig web and explorer interface? – Ashish Patel Nov 16 '11 at 17:39
  • When adding a folder using Explorer view there are no after properties (which is odd). When adding a file through explorer view I have "vti_filesize", which seems to equal zero even if the file has size, and "vti_parserversion" which is "12.0.0.6562". – Peter Nov 16 '11 at 17:47
  • see my update again.. I am not sure about the behavior using Explorer.. I am curious to know if sharepoint would cancel the action if it is not allowed! – Ashish Patel Nov 16 '11 at 17:53
6

With SP2010, You can use ItemAdded with Synchronization (instead of ItemAdding) to perform some operations after the item is created but before it is presented to the user. Then you can use if(properties.ListItem.File!=null)to determine if listitem has file associated with it.

To make ItemAdded synchronous, you need to set the Synchronization property either through the SPEventReceiverDefinition object model if you are registering your events programmatically or by creating below node in your XML that sets the value to Synchronous or Asynchronous.

<Synchronization>Synchronous</Synchronization>
Improve this answer
3
  • Thanks for the suggestion. Unfortunately properties.ListItem is always null during the ItemAdding event because the ListItem does not exist yet. – Peter Nov 16 '11 at 17:18
  • @Patricker,See my Edit above – Amit Kumawat Nov 29 '11 at 9:24
  • This looks like a great option. When we upgrade to 2010 I'll switch my code to work this way. – Peter Nov 29 '11 at 15:21
1

Old Post - but I've got this working in SP2010 ItemAdding and believe you almost had the answer in one of your comments:

When adding a folder using Explorer view there are no after properties (which is odd). When adding a file through explorer view I have "vti_filesize", which seems to equal zero even if the file has size, and "vti_parserversion" which is "12.0.0.6562". – Peter Nov 16 '11 at 17:38

The afterProperty "vti_filesize" is always null when dealing with folders. The "vti_filesize" is always non-null when dealing with documents. So simply check for "vti_filesize" to be null and you know it's a folder.

Improve this answer
2
  • Jon, we found that with SP2010 that what you are saying is the case, but that in SP2007 both files and folders showed a zero file size in Explorer view. Sp2007 at the time was what we were working with. – Peter Nov 9 '12 at 16:45
  • I figured that would be the case in Explorer View itself. Odd how it's non-null in the afterProperties though (from your observation). I'm only testing on SP2010, so hopefully this helps somebody on the newer platforms. – JonTheNerd Nov 9 '12 at 20:31
0

Why not just add pdf to the blocked file list:

http://technet.microsoft.com/en-us/library/cc262496.aspx

Improve this answer
1
  • Two issues with this approach. One, we dont want to block pdf, we want to block everything BUT pdf. Two, this setting is at the Web application level. We have a ton of sites with lists where we put no restrictions on the file type. – Peter Nov 16 '11 at 18:00
0

Simply, check if properties.BeforeUrl contains a dot (dots are not allowed in folder names):

string url = properties.BeforeUrl;
if (url .Contains(".")) //it is a file * not a folder
{
   //To do
}
Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.