Tuesday, September 14, 2010

Show Incoming Links on a Wiki Page - for SharePoint 2010

For those of you who saw my post on how to add the incoming links to a wiki page for 2007, it linked to a page that described how to add a bit of code to a CEWP and have the pages that linked to the wiki page display on the page itself. This prevented you from having to browse to a different page to see this information.

The last time I looked, there was no update for SharePoint 2010, and I desperately needed it for a project I was working on. I was lucky enough to get my hands on a SharePoint Developer who was able to hack it out for me. He took the liberty of changing the reference to the Google jQuery Library to Microsofts Library.

He also added a few things like spacing the text from the left of the page, and the ability to change the font size. Hope this helps - it works like a charm for my project!

<script src="http://ajax.microsoft.com/ajax/jquery/jquery-1.4.2.min.js" type="text/javascript"></script>
<script type="text/javascript">
$(function() {

function addLinks(){

//get the url for the incoming links page
var starturl = SP.Utilities.Utility.getLayoutsPageUrl('BackLinks.aspx');

var builder = new SP.Utilities.UrlBuilder(starturl);
builder.addKeyValueQueryString('List', (new SP.Guid(_spPageContextInfo.pageListId)).toString());
builder.addKeyValueQueryString('ID', _spPageContextInfo.pageItemId.toString());
var u = builder.get_url();

//create a target container and load it with the incoming links
//filtered to show the links list only

var l = $("<div id='incomingLinks' style='border-top: solid 1px silver'>").load(u + " #MSO_ContentTable .ms-bodyareacell", function(){

l.css("font-size", "11pt").find("a").css("padding-left", "11px").css("font-size", "11pt");
});

//append the new container to the wiki content


$(".ms-wikicontent").append(l);


}
ExecuteOrDelayUntilScriptLoaded(addLinks, "sp.js");


});


</script>

Friday, July 2, 2010

New InfoPath Functionality

I am a HUGE fan of InfoPath. I was just getting into the more advanced functionality of 2007 IP and then 2010 came and it was all over. I was not that enthused with some of the changes, since I was so used to where things were in 2007. However, I got over that disappointment quite quickly when I found some stuff that will make your end users go ga-ga.

Like the new Picture Button functionality that allows you to create hover-over effects on your buttons. And easy copy-pasting of rules from one control to another. This stuff really rocks. I have some developer friends who would disagree, since they say some of the coding has gotten more difficult. I can't comment on that. All I can say is, when you can automatically post your InfoPath form into a web page using an InfoPath Form Web Part, or when you can create rating buttons that allow your users to add ratings using star graphics, your forms can really sing and you will get more user buy-in. And isn't that what it is all about?

Check out my favorite video from the InfoPath Team Blog that details (in 5 minutes) (yes, that is FIVE minutes) how to use rating stars instead of option buttons for survey forms. 


They have a series of these that are all around 5 minutes, that are super easy to create and will make your forms look awesome.

As I get deeper into the functionality, I hope to post some of my findings. If you have a specific idea for things to try using the new functionality, let me know!

Tuesday, June 29, 2010

Smiling Goat

I love RSS. It is the best way to keep up with all of my favorite blogs, like the Scott Adams Blog (Dilbert), Scott Berkun's blog, and of course, Joel Oleson, Asif Rehmani, Shane Young... and the 15 or so most interesting SharePoint blogs out there.

Using the RSS Web Part is great. You can have all of your favorite blogs delivered to your MySite. However, SharePoint does not allow internal SharePoint RSS feeds unless you are using Kerberos authentication. Unfortunately, the company where I work does not currently use Kerberos, so, my internal SharePoint RSS feeds were - up until recently - non-existent.

But there is a workaround - as there is for most challenges in SharePoint. It's called the Smiling Goat Feedreader, which is available on Codeplex here - http://feedreader.codeplex.com/

The good:
It was extremely easy to install and deploy. It is simple for end-users to configure, and it surfaces RSS feeds for lists and libraries very smoothly with almost no cost to page load time. And the name always makes people smile!

The bad:
There is not a lot of documentation out there on this web part, which is one of the main challenges of freeware or shareware in general, and therefore, our security team was initially a bit squeamish about loosing a freeware web part in our production environment. If this is a concern for your security folks, make sure it is fully tested in your lower environments first. (Although, that said, Microsoft does refer to the web part favorably in some of their technet articles.)

Another annoyance is that the designer's initials show on the Web Part Title bar and there is no way to remove them. If you have a fussy site admin, they will not like this.

However, the advantages definitely outweigh the drawbacks. It is nice to finally get internal feeds on important document libraries and lists delivered right to my MySite or my own private pages. Our site admin likes it because always the 10 most recent documents display from the library, so it keeps her site current.

The Kerberos requirement for internal feeds does not change with SharePoint 2010. But don't let that get your goat! Instead, get the Smiling Goat!

Wednesday, June 16, 2010

Ready or Not...SharePoint 2010!

Well, I have finally done it! With three virtual machines running variations of the new SharePoint 2010, I am ready to start blogging about the new version. I still love 2007 and will keep posting about it as well. I know some people are not ready to make the leap yet. However, I was lucky enough to earn the position of Technical Editor for the new SharePoint 2010 Inside and Out book that is soon to be published and I have been sandboxing my little heart out trying to make each chapter a reality.

Also I have recently procured the new book by Todd Klindt, Shane Young and Steve Caravajal called "SharePoint 2010 Administration" and cannot WAIT to dig in! BTW, Shane Young is one of my very favorites and I have had the pleasure of teaching in his footsteps at SharePoint Solutions. I will keep you posted on the book and any new SharePoint 2010 tidbits I pick up along the way!

Tuesday, June 15, 2010

Moving a List with Large Attachments

I was asked the other day for assistance with moving a list that had attachments. My first thought was that I would just save the list as a template and recreate it in the site the user needed it in. However, that was a quick judgement based on my initial assumption that the attachments were of a manageable size. They were not - they were huge, and it made the list too large to save as a template. Publishing was not enabled, so I could not move the list using Manage Content and Structure. I figured I was in for a long night whereby I would have to save off each attachment and then reattach them once the list items were actually moved.

As a last ditch effort to save time (and my precious evenings with my most important SharePoint student) I tried to see if I could accomplish this in SharePoint Designer. As I played around with the list, I noticed that the attachments were saved in a folder called Attachments....

General Attachments folder at the root of the list.

...and in sub-folders from there where the title of the folder that matched the ID of the list item. AHA!
Folders under the Attachment folder. Note the folder name is the Item ID No.

Because while I could not move the list item itself, I could move the folder contents!

So, I exported the list to Excel to preserve the content. I also exposed the ID column to capture that information on the old list. On the destination site, I created a new list in SharePoint by importing the exported spreadsheet. (Take care when you do this that the column you want to link to the edit menu is the left most column before it is imported.)

Once you have your new list, open it up in SharePoint Designer. Again, you will have to match the IDs of the old list items with the new, since they might not match. Create new folders under the Attachments folder and name them according to your new attachments folder, then map the new folders to the old. So, from the old list, ID #15 might have an attachment, but you will need to ensure that the old #15 is the new #15 also.

After you create the new folders, simply copy and paste the items from each folder. (Note that it will not allow you to simply copy and paste the folders themselves, only the content.)

It worked great and my user was able to use her new list the very next day - without my having to spend the night at work!

Tuesday, June 8, 2010

ForeFront Error for Excel - Large Uncompressed File

We have begun to use SSRS in our environment. I am huge fan of what it can do, even though I don't know that much about it. One thing that it did allow our users to do is to download raw data. This is great, because now they have access to it. However, an issue recently arose when a user wanted to share that data on SharePoint with Forefront installed.

Recently, a user exported raw data from the SSRS into an Excel 2007 spreadsheet. He wanted to share that data with his team, so tried to upload it to a SharePoint library. It failed with the following error: Virus Name - "Large Uncompressed Size".

The file was not too large - only 33 MG. (Ok, that does sound large. But our upload limit is 150 MG, so it should not have had a problem.) During troubleshooting, I converted the file to a 2003 Excel file and it inflated the size to 88 MG, but it uploaded fine. It also uploaded fine in comma delimited text format. Additionally, I cut out half the data (down to 22,000 rows) and it uploaded okay. Just for fun, I created another worksheet in the same workbook and pasted the 23,000 rows I had cut from the first worksheet. It also uploaded just fine. Therefore, the problem was not the data and of course there was no actual virus.

Although we did not realize it until we had spent days testing, part of the issue actually had to do with the amount of rows and columns that the spreadsheet contained in a single worksheet - 45,000 rows and 250+ columns. The other part had do do with the XML structure of Excel 2007 documents. Forefront was actually timing out when it tried to read all of that XML data in one chunk. This is why dividing it up the data into smaller chunks allowed the document to upload successfully.

When we contacted Microsoft for problem resolution, they suggested that we turn off scanning for all Excel files. We informed them (very nicely) that this was against our security protocol. After a few days, they came back with a fix that involved adding two registry keys specific to Excel files that would increase the timeout limit on scanned Excel documents.

I have good and bad news. The good news is that this worked. The bad news is that due to Microsoft legalities with my company, I was not allowed to publish the registry keys that needed to be added. Apparently, this is "super confidential" and my network administrator did not feel comfortable letting me in on the secret. That said, I wanted to post this anyway in order to give anyone out there the comfort that there is actually a fix for this annoying problem.

By the way, there are a few Microsoft KB Articles out there that reference altering registry keys for a similar issues. Keep in mind these do not work for this particular Excel issue, but it is worth noting here:

http://support.microsoft.com/kb/972074 -Refers to the errors you recieve when you upload a document that contains smaller files that exceed the Forefront upload limit. It also mentions how to skip the scanning of these documents.

http://support.microsoft.com/kb/972072/ - Walks you through the process of eliminating large uncompressed files from the ForeFront scan.

Monday, June 7, 2010

Replacing the Default Permissions Email Text

For the longest time, our users had expressed their annoyance with the out of the box email template that is received when permission to a site is granted. Typically, the text give you a welcome message and then proceeds to detail out "What is a SharePoint site?" If your users are like ours and already are well-acquainted with what a SharePoint site is, it might be time to change that message.

Although it is recommended not to change any default files, doing this is reletively harmless if, of course, it is tested thoroughly and done with caution. The file itself is an XML and is located in the 12 Hive (c:\Program Files\Common Files\Microsoft Shared\web server extensions\12) in the Resouces folder. The file is called core.en-us.resx.

To edit this file, you will need to open it up in Notepad and press CTL + F to search for the text "What is a SharePoint Site?" Once you find it, you will want to replace everything from "What is a SharePoint site?" to "...members of the site can contribute their own ideas and content as well as comment on or contribute to other people's." with the XML character for a non-breaking space (@#160). This will keep all of the tags in place and you will recieve emails without any text below the name of the site and the type of permission you were given.

Additionally, you will need to revise your documentation for installing service packs to include backing up this file before the Service Pack install and reapplying it afterwards, since it will most likely be overwritten when Service Packs are installed. However, when I recently installed the February Cumulative Update in my 2007 environment, and it did not affect this file.

Tuesday, April 27, 2010

It’s called “All Items” for a reason!

One of the users where I work called in a panic. She had just finished creating an important document and saved it to SharePoint but she could not find it in the library. Before she called me, she checked all the views to make sure it wasn’t there, checked her local drafts folder to make sure it wasn’t checked out and it wasn’t anywhere she looked.


For troubleshooting, I looked in the checked out files to make sure that there was no required field that was empty and preventing the document from showing up. I checked her permissions, and checked that she had, at one time, been able to upload and modify documents in this library. Nothing.

It was indeed perplexing.


Now, I know that all the SharePoint opposers are probably out there, saying, “See? You can’t trust SharePoint with your documents! This never would have happened with a network drive!” She was certainly one of them. She could not believe that SharePoint had “betrayed” her and vowed to save everything to her hard drive before uploading it. Well, she was right about one thing - it never would have happened on a network drive. The reason is that network drives do not allow us to sort and filter views of our documents by metadata.


The issue in this case, was that someone made a change to the AllItems.aspx view that suppressed documents with a particular set of metadata. Because our user did not set the filter rules on the view, she was unaware of this. Instead, she saved her document to the library, applied the metadata tags, and blamed SharePoint for losing her document.


The moral of the story? Just because you can, doesn’t mean you should. SharePoint gives us a lot of opportunity to help make our work lives easier, but it also provides ample means of hosing us, too. Make sure when you are creating or modifying views, leave the AllItems.aspx view as it stands so you always have a view of library that displays all the documents.

Thursday, February 4, 2010

Show Incoming Links on a Wiki Page

I got this great script for showing incoming links on a wiki page in SharePoint from a post at http://mo.notono.us.com/. (Here is the full link to the original post http://mo.notono.us/2009/01/moss-add-incoming-links-to-wiki-page.html.)

To place it on the page, edit your wiki page and drop in a Content Editor Web Part. Then open the source editor for the web part and drop this code in. Works like a charm!

As Oskar mentions in his post, you can also add it to the master page for your wikis. There are reasons not to, of course. But it may be a great solution depending on your circumstances.

Thanks Oskar for this great tool!

<script src="http://ajax.googleapis.com/ajax/libs/jquery/1.2.6/jquery.min.js" type="text/javascript"></script>

<script type="text/javascript">
$(function() {
//get the url for the incoming links page

u = $("a[id$=WikiIncomingLinks_LinkText]")[0].href;
//create a target container and load it with the incoming links
//filtered to show the links list only
l = $("<div id='incomingLinks' style='border-top: solid 1px silver'>").load(u + " .ms-formareaframe");
//append the new container to the wiki content
$(".ms-wikicontent").append(l);
});

</script>

Monday, February 1, 2010

Hide the Left Navigation Pane using a CEWP!

Is that left-navigation pane an annoyance? Hide it using a Content Editor Web part!


Place a content editor web part on your page and click the drop-down to edit it. Click Source Editor and enter the following code:

<style>.ms-navframe{ display:none; }</style>

Make your Content Editor Web Part hidden and click OK.

Your page should now have the left-navigation pane hidden!

Friday, January 22, 2010

Clearing an Option Button in InfoPath

While this is basically a SharePoint blog, I use InfoPath a lot paired with SharePoint. They are pretty amazing together. An InfoPath form template saved to a SharePoint document library can store important data that can be displayed in a report-like fashion, manipulated into views, used to fire workflows, and much more. Additionally, the fact that Microsoft made the licensing all-encompassing for the Office Suite and gave InfoPath browser compatibility ensures that it will be an integral part of the workplace for decades to come. It is a great tool for gathering information from your organization.

However, although InfoPath is a great program, it is not intuitive. In fact, sometimes it is downright annoying. (Although I am sure the same can be said for SharePoint at times, right?)

I was working with a existing form that I needed to modify and I wanted to add some conditional formatting to make certain sections display when the option button selected was "Yes" and to disappear from view when the option button selected was "No." The challenge I ran into was that I could make the section disappear when "No" was selected, but if the user had inadvertently clicked on an option button in the section being hidden, that field stayed populated, hidden or not. Because this information was being sent to a database in addition to being published on SharePoint, I needed to clear the option buttons on the sections being hidden.

Here is the scenario:

OptionButton1 - Yes = True, No = False, No value is set as a default selection
OptionButton2 - Yes = True, No = False, No value is set as a default selection
However, OptionButton2 should be NULL if OptionButton1 is set to False (No)

So I created a rule to change the value of OptionButton2 based on a False value for OptionButton1.

OptionButton Properties --> Rules --> Add
Condition - OptionButton1 = False
Action - Set a Field's value
Field - OptionButton2
Value - ?????

Here is where I hit the snag. The value choices for OptionButton2 only had the following: (blank), TRUE, FALSE, 1 or 0. Choosing (blank) did not work and I didn't want the other options, since I wanted no value whatsoever.



















It was a puzzle. The fix? Leaving the "Value" field completely blank. Obvious, you say? Well, it wasn't to me. But it worked like a charm!



Thursday, January 21, 2010

Alerts for Email Accounts

Often you will want to have an alert for a distribution list or an email account that is not associated with any particular user. While this may seem straightforward, I ran into an issue with this when I tried this recently and it was due to some issues with how we handle the creation of distribution lists and open email accounts in our environment. Therefore, if you want this to work, you must make certain of the following:

  • Ensure your email account is set to "Enabled" in AD. (In our AD, they are disabled by default)
  • Once they are enabled, they will need to be granted access to the site and/or document libraries/lists where the alerts are being set.
Once these steps are complete, your email account should begin to receive alerts.