Monday, October 11, 2010

Emails with attachments don't appear in document libraries

Emails to a SharePoint 2007 document library have some "gotchas" when it comes to attachments. Filenames and encoding can both cause silent failures; the email appears to be sent correctly, but the doclib is unchanged, and no error appears to the user, either via return email or on the website.
Filenames may contain characters that are valid in your desktop OS, but are not valid for Sharepoint. Microsoft lists the bad guys in this Knowledge Base article:
Information about the characters that you cannot use in sites, folders, and files in SharePoint
I follow this simple rule: don't use punctiation other than underscores in filenames, and don't put an underscore first.
Encoding of attachments may also be an issue. Testing on our SharePoint 2007 site indicates that attachments in the AppleDouble format (often the default for email clients on the Macintosh) cause the email to fail silently. Be sure to "encode for Windows" if sending from a Mac email client. [Note that GMail uses MIME/Base-64 encoding, which SharePoint accepts.]
Enhanced by Zemanta

Wednesday, July 21, 2010

SharePoint Overview

Posted to in response to a thread about SharePoint vs. Google Apps for a small church organization:

 I think about SharePoint in the following terms (YMMV):

SharePoint at its core is web-based file sharing. Conventional LAN file shares have some major drawbacks:  you have to be on the LAN to access them, and it's difficult to include and utilize metadata. and.  SharePoint began by addressing these two issues.  [Today's SharePoint also includes document management features like global search and workflow.]

If you ask, "Why do people share files?", the short answer is, "They're collaborating".  So SharePoint includes collaboration features like check-out/check-in, announcements, calendars, and discussions.  This is the basis of the "teamsites".

It is common in today's project-oriented workplace for people to work on several project teams.  Some integrated view of multiple teamsites is needed, so SharePoint includes portal features like MySite.  [Today's SharePoint also includes "social" features like "Colleague Tracker".]

Now that SharePoint is collecting all those eyeballs, it becomes attractive as a business application platform.  Data views, Business Data Connector, Key Performance Indicators, and so on follow.

With so much web-based business function co-located on the SharePoint platform, it is also attractive to integrate content management;  hence the Publishing feature.

So you can consider SharePoint an integrated suite of web-based applications for file sharing, collaboration, business information, and publishing.  If all you need is file-sharing, there are simpler alternatives.

Alex is exactly right:  details are king.  The problem is that the details of the work that people need to do are often hidden from the person who makes the decisions about what platform they will use.

-- Joshua

Enhanced by Zemanta

Thursday, April 29, 2010

Controlling access to content for anonymous users?

sharepointdiscussions : Message: RE: [sharepointdiscussions] How do you control access to content for anonymous users?

This post discusses a simple way to deny access for anonymous users to particular pages within a public publishing site.  [Sorry, Yahoo registration required.  I thought it was public :-( ]

Wednesday, April 14, 2010

Moving A Site - "Export ran out of memory"

Another hitch in the site migration saga (see my earlier post).  Some sites I am migrating reach the "Compressing File(s)" stage, then error out:

FatalError: Export ran out of memory while compressing a very large file. To successfully export, turn compression off by specifying the -nofilecompression parameter.
So the really big .cmp/.cab files I was creating can't be compressed.  The solution suggested in the error message is not attractive, since these are files that have to be transmitted over the network.  My solution:  cut the "-cabsize" parameter on the "stsadm -o export" command back to "60". The export ran to completion,  the SharePoint Designer "Restore website..." operation was successful, and the site actually looks correct.

The one gotcha I saw had to do with the "60" (megabyte) limit on the size of the .cmp/.cab files.  This particular site was exported as 6 files, with sizes (in order of creation) of 89, 86, 82, 64, 68, and 56 megabytes.  Examining the contents of the 89MB .cmp file (by simply changing the file extension to .cab and double-clicking), showed that the last file added to the .cab was 47MB (an .mp3).  Probably the export process doesn't look ahead at file sizes to determine when to switch to building the next .cab file, but waits to detect the occurrence of the overflow.

So admins migrating SharePoint sites with (even moderately) big files, beware!

Monday, March 22, 2010

Moving A Site - "Restore Did Not Complete Successfully"

I have been migrating sites from one SharePoint farm to another by means of making a "backup" or "export" from the source server and doing a "restore" or "import" on the destination server.  This is not as simple as it seems, since Microsoft is determined to make it confusing (which is not far from making it just plain difficult).

Friday, February 19, 2010

Using [Today] or [Me] in SharePoint calculated columns

One would like to be able to use dynamic information like [Today] or [Me] in calculated columns (for example, to compute "Age" from "DateOfBirth"), but SharePoint complains.

Steve Eagleson was kind enough to point out this article from "Novotronix":

Novotronix Blog - Using [Today] or [Me] in SharePoint calculated columns

which contains a workaround which seems to... um, work.

The workaround involves creating a temporary column called "Today", then creating the formula, then deleting the temp column. This suggests that SharePoint actually knows how to use the dynamic variable, but the parser rejects it when the formula is saved. Very odd...

Tuesday, February 16, 2010

Displaying Attachments to SharePoint Blog Posts

Where I work, we are interested in creating online "learning histories" of our activities.  We conceive of the learning history as a set of brief reflective essays, usually contemporaneous with the events they describe, and sometimes accompanied by (or accompanying) document artifacts. This sort of sounds like a blog with attachments, especially because blogs put chronological organization in the foreground.  

We would like to add entries in the learning history by email as well as via web interface.  So I set up a SharePoint blog, enabled attachments on the "Posts" list, email-enabled the list, and sent an email with attachments.  When viewed via AllItems.aspx, the paper-clip icon was present, but the attachments did not appear when the post was displayed on the Home page or the Post.aspx page.  They did, however, appear on the EditPost.aspx page.  So I knew they were in the system.  [See more information on this in my post "Emailing to SharePoint Blogs".]

I googled and found a post <> that seemed to address the question directly.  The first part of the post deals with changing the site definition of blogs so that "Add Attachment" appears in the "New" and "Edit" page toolbars.  Since I don't have access to the 12 hive for this site, and I know I can get attachments in via email, I skipped to the next step, which reads:

If you want to display the attached files in your post please convert the Web Part in your post.aspx that shows the “post” to an XSLT DVWP.
Fix the Author problem by removing the = character before =@Author and thenfollow the guide below:

Now you have to open the post.aspx of your SharePoint 2007 blog and add the code linked from :

This is a little sketchy, so here is the detail as I experienced it:

The conversion referred to in the first sentence is accomplished in SharePoint Designer.  I started this work by opening the Post.aspx page in SPD, then before doing anything else I saved it under another name (Post-test.aspx).  I did all my testing on this page.  This way, I could test in the live site without interfering with production.

To convert the List View Web part to a Data View (XSLT) Web Part, open the page, select the "Posts" web part (which is displaying "There are no posts in this category."), right-click, and choose "Convert to XSLT".

SPD will complain that it can't display the web part. This is the "Author" problem described by pampigt.  Use the "split" icon to display both the "Design" and "Code" modes, find "=@Author", and change it to "@Author" (there's only one occurrence).   Then save the page — the display will be refreshed.

Then I discovered a problem not described by "pampigt".  I tested the page at this stage, and found that in the browser, it displayed the "There are no posts in this category" message.  Examining the XSLT, it appeared to me that this meant that there were no rows returned by the query.  After much munching around, I found the key to this step:  Using the little arrow-head next to the web part, I opened the Common Data View Tasks menu, and selected "Filter:"  I knew I needed to filter on ID, so I selected that as the field name, and I selected "Equals" as the comparison.  Then, under "Value", I knew I needed value of the query string parameter ID, but that didn't appear in the dropdown.  However, "Create a new parameter..." did appear, so I selected it.  I gave the parameter name "ID" and the source as "Query String".  A few "OK"'s later, I saved the page and tested in the browser.  First Victory!

Now to get the attachments listed on the page.  For this, I used the code linked by "pampigt" from Dario Martirani <>.  His Data View Web Part (he uses the older name "Data Form Web Part") is much simpler than the converted List View Web Part in Posts.aspx, but I took the XSL code for the dvt_1.rowview template and inserted it right above the "Posted at" part of the XSL for my Data View Web part.  I added a test so the code wouldn't be used if there were no attachments, and a <br /> at the end.  Save, test in browser — Second Victory!

Here's the XSL code I ended up with:

   <xsl:if test="@Attachments!='0'">
           <xsl:element name="SharePoint:AttachmentsField">
          <xsl:attribute name="runat">server</xsl:attribute>
          <xsl:attribute name="ListId">
          <xsl:attribute name="FieldName">Attachments</xsl:attribute>
          <xsl:attribute name="ControlMode">Display</xsl:attribute>
          <xsl:attribute name="Visible">true</xsl:attribute>
          <xsl:attribute name="ItemId">
              <xsl:value-of select="@ID"/>
          <br />

Note that, contrary to Dario's post, this appears to work even though the "ListId" attribute is not set to the correct list.  I suppose that the "AttachmentsField" control is getting its context from somewhere other than its attributes...

As the last step, I opened Post.aspx in SPD and saved it as Post-dist.aspx (the version distributed), then put the test page into production by saving it as Post.aspx, so the new version is the target of all the right links.

Remaining issues:   
  1. adding attachment capabilities in the NewPost.aspx and EditPost.aspx pages (without modifying the 12 hive if possible)
  2. adding display of attachments to the blog home page

Emailing to SharePoint Blogs

There are several places to find information on how to "email-enable" a SharePoint 2007 blog -- that is, to make it possible to post to the blog by sending email to it. At my job, I am helping to set up our "Rain King Chronicle" blog to do exactly that, and learned some interesting things about the process, particularly with regard to attachments.

Wednesday, February 10, 2010

Mobile App and OS UI's: A Lot To Learn

Jakob Nielsen has (as usual) some interesting and provocative insights about usability, in this case the usability of iPhone and other mobile apps:
iPhone Apps Need Low Starting Hurdles (Jakob Nielsen's Alertbox)
Nielsen says
The "master guideline" remains the same as in 1986: don't port a UI from an old interface paradigm to a new one.
Nielsen also points out that "on mobile devices, applications are easier to use than websites". Maybe we should look for ways to app-ize our websites for mobile users, rather than make "mobile-friendly" sites that depend on mobile browsers.

On a related note, Slate's Farhad Manjoo says Google's Android OS has a usability issue: "constant menu hunting".
What's Wrong With Android
Manjoo traces the difference between the iPhone user experience and the Android UX to a difference in philosophy:
...Apple is clearly trying to make a complete break with desktop operating systems... under Android's design philosophy, menus are a natural consequence of complexity... That's a familiar view of computing, one deeply tied to the interface on the standard PC...
So Nielsen would probably echo Manjoo's plea to the Android team: "join the menu-free bandwagon!"

And maybe we should rethink our web apps' UX with a more "mobile" mindset.

[On a side note: According to a correction notice on the Slate page linked above, the screenshots of the iPhone and Android calendars had their labels swapped initially. Somehow I doubt that anyone actually believed that the picture from the Android phone was something that ever appeared on an Apple product. Android has more problems than just menu-itis.]
Reblog this post [with Zemanta]