Questions? Call Us 800.260.9357
Home
Our Work
Services
Small Business Intranet
Samples
Training
SharePoint
  

dbWeb > Blogs > Brandt Fuchs

It's been a while. Happy New Year!
1st post in quite some time, the second half of 09 seemed to fly by. So much has happened. The SharePoint 2010 conference in Vegas was a blast. There are so many improvements and innovations in SP 2010 that we here at dataBridge as well as our clients are thrilled for the official launch later this year. We've are enjoying playing with the betas and creating rich solutions using the new and improved services in Microsoft Sharepoint Server. One of the things I am most excited about is the fact that the Business Conectivity Services (new BDC) is available in SharePoint Foundations (new WSS, the free SharePoint). What this means is that even in SP Foundations, sharepoint can be the hub for all line of business data. :)
Use a MOSS Web Service to Obtain User Data
Here is what I believe to be the most userful web service that MOSS provides out of the box, the UserProfileService.
 
 
This web service can be utilized to obtain a large set of information about the current user.  Below is a list of the value names that you can return by calling this web service.
 
UserProfile_GUID
AccountName
FirstName
LastName
PreferredName
WorkPhone
Office
Department
Title
Manager
AboutMe
PersonalSpace
PictureURL
UserName
QuickLinks
WebSite
PublicSiteRedirect
SPS-Dotted-line
SPS-Peers
SPS-Responsibility
SPS-Skills
SPS-PastProjects
SPS-Interests
SPS-School
SPS-SipAddress
SPS-Birthday
SPS-MySiteUpgrade
SPS-DontSuggestList
SPS-ProxyAddresses
SPS-HireDate
SPS-LastColleagueAdded
SPS-OWAUrl
SPS-ResourceAccountName
SPS-MasterAccountName
Assistant
WorkEmail
CellPhone
Fax
HomePhone
 
I obtained this list by calling the web service into an XSLT web part in SPD and displaying all Names.
 
These properties are all obtained from the Shared Services Provider's User Profile directory that is synced with AD.  Often I find companies will have AD sparsely populated with very few of these fields actually containing data.  But the more data that is populated about each user, the more that we can leverage the user profiles.
 
For instance, we can call this web service from InfoPath and have it return the current user and their manager, which could then be used in turn in a workflow to route the form for approval.
 
We could also create a linked source in SharePoint Designer that links this web service with a list of PTO data.  We could then filter the PTO data to only show employees taking PTO for my office based on that value from the web service.  This provides for a much more focused view of PTO data by only showing the employees in the same office as the current user.
Displaying Attachments in Multiple Item Xslt Data View Web Part
So I had posted an item previously about displaying attachments in a data view web part.  My previous post only works when using a single item view. When working with a multiple item view some modifications to the code are needed.
 
At first I tried this code
 
<SharePoint:AttachmentsField ControlMode="Display" ItemId="{@ID}" EnableViewState="true" FieldName="Attachments" runat="server"/>
 
I though that adding the ItemID attribute would be sufficient, however this proved not to be the case.  The issue I experienced is that this code works in a single item view, but in a multiple item view it selects first item's ID as all item's 'ItemID' attribute on the SharePoint:AttachmentsField control.
 
The result is that if the first item has an attachment, that attachment is displayed for all items.  Likewise if the first item has no attachments, all items display no attachment.

It is obvious to me that the SharePoint:AttachmentField control is not receiving the correct ID for each item, but rather all are receiving the first item's ID.  I can't tell why that is though.

I managed to figure this one out, although I must admit the solution supprised me.  What I did was add the following code right before my SharePoint:AttachmentField control

<SharePoint:AttachmentButton ControlMode="Edit" Enabled="true" ItemId="{@ID}" runat="server" Visible="false"/>

So the code that displays attachments on a multiple item view is as follows.

<SharePoint:AttachmentButton ControlMode="Edit" Enabled="true" ItemId="{@ID}" runat="server" Visible="false"/><SharePoint:AttachmentsField ControlMode="Display" ItemId="{@ID}" EnableViewState="true" FieldName="Attachments" runat="server"/>

SharePoint on a Blackberry
So in order to work with SharePoint forms from your blackberry, there are a few tweaks that need to be made to your BB.

First, open the browser on your BB

Second, open the options and select Browser Configuration

Third, check the boxes for 'Support JavaScript' and 'Allow JavaScript popups'

Lastly, scroll down and change the Emulation Mode to 'MS Pocket IE'

That was all the changes that I had to make allow me to interact with a SharePoint site from my BlackBerry. I hope that helps!
Printer Friendly Pages
I often hear, 'can I get a printer friendly display of the data within sharepoint?'  I've seen a feature around that add a menu button to list toolbars - here.  I went down another route to accomplish this, and I'll admit it's not the most elegant solution as it could be packaged into a feature.  It does however allow users to print the content on any page attached to the master page rather than just lists with a toolbar.
 
This will allow you, from any page that is attached to the master page, to hide all but the main content area so that you can print a page without the extra content using up all the ink in your printer. Of course this is not as elegant as a feature that would deploy across all sites, but it works and if some body wants to wrap it up into a feature, go right ahead.
 
Insert the following divs onto the masterpage, wherever you would like to see the buttons to change views from a non printer-friendly view to a printer-friendly view.
  
<div id="printbutton"><asp:Button CssClass="ms-vb" runat="server" UseSubmitBehavior="false" OnClientClick="javascript:PrinterFriendly();return false;" Text="Print-Friendly" id="Button1" CausesValidation="False" EnableViewState="False" /></div>
 

<div id="nonprintbutton" style="display:none"><asp:Button CssClass="ms-vb" runat="server" UseSubmitBehavior="false" OnClientClick="javascript:NonPrinterFriendly();return false;" Text="Non Print-Friendly" id="Button2" CausesValidation="False" EnableViewState="False" /></div>

Insert the following javascript in the head tag of the masterpage. (replace content this color with the IDs of the elements you want to hide/show)
 

<script type="text/javascript" language="javascript">

function PrinterFriendly(){

                document.getElementById('id of area you want to hide').style.display="none";

                document.getElementById('id of area you want to hide').style.display="none";

                document.getElementById('id of area you want to hide').style.display="none";

                document.getElementById('id of body or outermost element to fit within a page width').style.width="7.5in";

                document.getElementById('nonprintbutton').style.display="";

                document.getElementById('printbutton').style.display="none";

}

function NonPrinterFriendly(){

                document.getElementById('id of area you want to show').style.display="";

                document.getElementById('id of area you want to show').style.display="";

                document.getElementById('id of area you want to show').style.display="";

                document.getElementById('id of body or outermost element to be fullscreen').style.width="100%";

                document.getElementById('printbutton').style.display="";

                document.getElementById('nonprintbutton').style.display="none";

}

</script>

You will have to go through the master page and add a few IDs to the areas that you want to hide/show so that you can reference these areas with the above javascript. You could use this code to hide and show any part of the site that you might want to print.
InfoPath Controls with SharePoint Lists as a Data Source
I was recently building an InfoPath form and had a number of dropdown controls that used information from SharePoint lists as their data sources.  I noticed when I previewed the form that only the first 100 items were returned to one of these dropdown controls.
 
I googled 'infopath 100 items from datasource' and quickly found this post that explains that when using a SharePoint list as a datasource, the items returned will be the items from the default view of the list that is your datasource.  This was easy enough to comprehend and so I tried to go fix my default view.
 
Now I don't know if this has anything to do with what I was experiencing, but my default view is a datasheet view.  When I went and looked at the item limit for this view, 'Display all items' was already selected.  This seemed to be a little inconsistent with the  post I had read, which is what prompted me to post my findings here.  Even though Display All Items was selected I change the # in the 'Limit Total # of Items' option to 500, and kept the first radio button checked.
 
When I saved the changes, even though visibly nothing had changed on the default view, my InfoPath form dropdown control now returned all 176 items.  Problem solved. 
Windows SharePoint Services 4.0 - XSLT Views
According to Microsoft http://support.microsoft.com/default.aspx?scid=kb;EN-US;956450 the next version of SharePoint is going to use XSLT web parts instead of the current default list views.  If you've read even a few of my posts then you know that I love working with XSLT, so this is good news for me!
GoGo Gadget-Lack-of-Documentation
I was doing a bit of digging through the most informative source of SharePoint documentation - my fellow SharePoint professional's blogs - and I discovered something that could have serious consequences for many organizations.  Take a look at Dave Wollerman's blog post entitled Huge MOSS Workflow Issue... What is Mircrosoft Thinking!!!!.  Here is the scoop in short; workflow history is purged after 60 days!  That's alright, it's no big deal if you don't care about storing your information for more than 2 months.  For those of us that live in the real world though, this could be very detrimental, especially for organizations that get audited.
 
I have been working very extensively with an international asset management firm for over a year now, and they get audited regularly.  Luckily for them, the way I build my workflows does not rely on any information being stored within the workflow history.
 
Rather than logging events in the workflow, and assigning tasks that are associated with the item that the workflow was initiated from, I have always opted for a simpler approach.  Now when I say simpler I mean from an end user perspective, not an initial setup/design perspective. 
 
I don't like assigning tasks to users through a workflow because the e-mails that users receive from a newly created task are just too cluttered.  There is a handful of links that take users everywhere except you tube, and in my experience this results in too much confusion to be productive.
 
I also don't like navigating into the workflow details screen to see what has happened.
 
My approach to designing workflows that are simple, easy to understand, and effective, revolves around one concept - centralization.  Rather than having a list item, a workflow, and many associated tasks, all to accomplish one process, I send out custom e-mails from the workflow that link to custom XSLT data form web parts that allow users to update hidden fields on the same list item from which the workflow was initiated.  The end result is that all auditable information is stored in hidden fields on the list item.  These fields can then be displayed on a custom XSLT data view web part as an audit page.  This way when 60 days go by and your workflow goes down the drain, all of the important information is still available via the list item.
Auto-Populate a People or Groups Field With the Current User Name
***Update:  This code does not work in Firefox***
 
I'll start this post with a disclamer that this code is not my own, I found different parts of the following code in different blog posts around the internet, but could not find this complete solution in one coherent post, so I decided to put it up myself.  I found the beginning of the code here.
 
Place the following code just inside the PlaceHolderMain tag of a newform.aspx page, or on a page with any custom form on it, and it should automatically populate a people or groups field with the name of the currently logged on user.
 
<script type="text/javascript">
_spBodyOnLoadFunctionNames.push("fillDefaultValues");
 
function fillDefaultValues() {
  var qs = location.search.substring(1, location.search.length);
  var args = qs.split("&");
  var vals = new Object(getUserDisplayName());
 
  var assignedToInput = getTagFromIdentifierAndTitle("div", "", "People Picker");
  assignedToInput.innerHTML = vals;
  for (var i=0; i < args.length; i++) {
    var nameVal = args[i].split("=");
    var temp = unescape(nameVal[1]).split('+');
    nameVal[1] = temp.join(' ');
    vals[nameVal[0]] = nameVal[1];
  } 
}
 
function getTagFromIdentifierAndTitle(tagName, identifier, title) {
  var len = identifier.length;
  var tags = document.getElementsByTagName(tagName);
  for (var i=0; i < tags.length; i++) {
    var tempString = tags[i].id;
    if (tags[i].title == title && (identifier == "" || tempString.indexOf(identifier) == tempString.length - len)) {
      return tags[i];
    }
  }
  return null;
}
function getUserDisplayName() {
 var tags = document.getElementsByTagName('a');
 for (var i=0; i < tags.length; i++) {
  if(tags[i].innerText.substr(0,7) == 'Welcome') {
   return tags[i].innerText.substr(8,tags[i].innerText.length);
  }
 }
}
</script>
Web Part Page Error
Sometimes when opening a SharePoint web part page you will see an error that references the ability to go the Web Part Page maintenance.  This allows you to remove any web parts that you think might be causing the error.  This is very useful, if it comes up.  I just recently came across a scenario where ther erroneous web part was closed on the page (which means you can only see it in SPD, and that no error occurs in the browser).  When trying to access the page in SPD I get an error that say I cant open the page and should try the web part page maintenance.  The downside is that this error message does not give you a link to that page. 
 
So here is how to get to the web parts page maintenance for any page.  Simply navigate to the page with the issue and ad a query string 'contents=1'.  For example navigating to http://intranet/default.aspx?contents=1 would take me to the web parts page maintenance for the home page.
 
1 - 10 Next

 ‭(Hidden)‬ Admin Links