Then again – I guess I was dealing with a group of engineers, so I should not be surprised.

So, one thing that became painfully obvious, as we were going through this exercise, was that the guys writing the user stories did not know much about SharePoint. We figured this out after about the 20th time I said “we will just make that a standard SharePoint Person or Group column, and all of that other stuff just comes along for the ride”. Wait – I might be selling my own cognitive skills short…let’s say it only took 15 times before I was able to discern the pattern.

At any rate, it occurred to me that, if the client had a good list of the standard SharePoint column types, they could consolidate several tasks in every user story that said things like “field should be a pick list”, “field should list the widget types”, “the widget types should be in a central location”, “field should be required” and “field should allow ‘Write-In’ values”…and consolidate it down to “field should be a standard SharePoint lookup field with these parameters: Lookup List: Widget Type | Required: Yes | Unique: No | Fill-In: Yes”

So, here are the learning points, at least for me.

1. Keep the following list handy. I also uploaded a PDF of the list. You can download that here:

List of Standard SharePoint Column Types

2. Give it to the client early in the process. Trust me – they will appreciate this standardized approach over having to provide, and think separately about, every detail pertaining to every field or column.

Here is the list.

The Fantastic InfoPath Voyage

Also on the agenda for the near future – a webinar of this presentation, including building out the Customer Discount Dashboard at the end. For those at the session this weekend, I apologize for not building the dashboard during the presentation.

As I mentioned during the session, I shortened the presentation timeline by “prepositioning” a lot of the SharePoint artifacts and code. The Good News – I ended up with more time. The Bad News – I totally spaced it on building the dashboard. In my defense – that WAS the first time I ever did not run out of time giving the presentation, so I think the “prepositioning” thing was a net win. Plus, made up words are fun.

Anyway, Q&A is a reasonable substitute for showing you how to build a web part page with two web parts on it, that are both views filtered by the “Form Status” attribute we beat to death during the bulk of the presentation, right?

The article expands slightly on a concept presented by Jan Tielens, SharePoint MVP, on his wonderful blog at: http://weblogs.asp.net/jan/default.aspx

Also referenced in the article, Marc Anderson’s awesome SharePoint jQuery library, which can be found at: http://spservices.codeplex.com

Please check out the article, and don’t forget to follow Jan and Marc on Twitter:

Jan – @jantielens

Marc – @sympmarc

Me – @mack247

(THIS POST ASSUMES THAT YOUR SOLUTION IS DEPLOYED AND MANAGED AT THE SITE COLLECTION LEVEL.)

Here is the scenario:

• You have a SharePoint solution (WSP) with a couple of web parts in it…everything is running smoothly
• You add another web part to the solution
• The new web part works fine in your “DEV” site collection
• You deploy the WSP to your TEST/PROD environment and run the Update-SPSolution PowerShell command
• You browse to your site collection, edit a page, go to add your new web part to see it in action, and…
• WHERE IS MY NEW @*&#!#$ WEB PART!?!?!

Fortunately, the solution to this annoying issue is simple.  Go to your Site Collection features, Deactive and Re-Activate the solution’s feature on your site collection.  That’s it.

Told you…simple.

P.S. You can Retract/Delete/Add/Deploy until you are blue in the face…until you deactivate and re-activate, you are S.O.L.

The host, Chris Coleman, was more gracious than I deserved and kind enough to ask me questions about which I had some manner of discrete knowledge, or could at least converse semi-intelligently.

By way of explanation, here is the origin of the “Ham Sandwich”.  I have a penchant for stopping discussions, particularly discussions about naming things, with a statement similar to, depending on the audience, “I don’t care what you [expletive optional] call it; call it a [expletive optional] [expletive optional] ham sandwich and let’s get back to the purpose of this discussion – helping you get the right information in front of the right person at the right time to make the right decision.”

You can listen to the archived broadcast on the BlogTalkTadio site here:  http://www.blogtalkradio.com/collaborationpizza

You can learn more about Yakabod, the game-changing Knowledge Management software company that sponsors the show, at their corporate website: http://www.yakabod.com

If you want to reserve me for a future interview or writing engagement, just hit me at joe.mack@theportalgroup.biz or on Twitter @mack247.

Thanks to Chris Coleman, Arpana Sharma, and the entire team at Yakabod that made it such a great experience for me.

One last thanks to InsaneWiches.com for the very cool ham sandwich picture.  I asked Uncle Google for an image of a ham sandwich and ended up spending 10 minutes on their site.

Enjoy!

SharePoint Saturday Columbus – The Great InfoPath Voyage

I will be adding to this post within the next day or so, with a link out to the code for the presentation as well.

Thanks for coming to my session, and thanks for the Twitter follows @mack247.

Also, thanks to SharePointSupport.com for footing the bill for me to come to speak to everyone. Please check out our SharePoint Support and Administration services at www.sharepointsupport.com. Thanks!

I am going to be building out a comprehensive solution based on InfoPath 2010 and SharePoint 2010.  We are going to have all the tools open at some point – Central Admin, InfoPath Designer, SharePoint Designer, Visual Studio, you name it.

Here is the official abstract for the session:

The Fantastic InfoPath Voyage

Join SharePoint Saturday veteran Joe Mack as he takes you through an end-to-end solution using Microsoft InfoPath and SharePoint 2010. After a brief introduction to some of the key new features in InfoPath 2010, we will: design and deploy a form template for use in the browser through Forms Services; develop a custom WCF service, host it within SharePoint 2010 and wire it up to our InfoPath template; create an on-form State Machine and link it to SharePoint metadata; automate the archival of completed forms to a SharePoint Records Center using SharePoint Designer workflow; and use the very cool ECMAScript Client Object Model to open the forms in a Modal Dialog.

So, if you are already signed up, I look forward to seeing you in Columbus.  If not, then you will be able to get the slides and code here shortly after this Saturday.  Depending on the technology present in Columbus, there might even be a video of my session available somewhere.

Stay tuned to this space for updates.

At any rate, there is a patch, Microsoft Security Bulletin MS10-130 (KB983444), that shipped as part of the June “Patch Tuesday” last week. The patch is supposed to fix a security hole whereby a user could elevate his or her privileges on WSS 3.0 all by themselves.

Great idea on paper right? Regular users making themselves site collection admins sounds like a bad thing, and fixing it must be good. Well, several users have been posting to the SharePoint Forums that, after applying the patch, they are seeing an “Unable to connect to configuration database” error, apparently even on Central Admin. There have been reports that running the SharePoint Configuration Wizard has fixed the issue in some cases, but not all of them.

It’s kind of funny that I heard the Hippocratic Oath-y phrase “do no harm” put forth by a SharePoint MVP just this week as the mantra of the SharePoint Product Team when working on the WSS 3.0 / MOSS 2007 to SPF 2010 / SPS 2010 upgrade process. Also adding to my personal giggles over this is the fact that I shared a Twitter thread with some friends this week about some great free products in the open source community and personally remarked that sometimes you really don’t get what you pay for.

While no “Patch Tuesday” being called “Black Tuesday” scenario is good for Microsoft, it just seems funny to me after seeing those Tweets. You can just picture someone at Microsoft saying — at least the free stuff is messed up. Could you imagine if we messed up MOSS installations? Now THAT would be bad.

As exepcted, Microsoft is sort of not really acknowledging the issue yet, but probably scrambling behind the scenes to get a fix. Given their recent track record of being highly successful at delivering good patches and quickly fixing those that aren’t good, I would expect this issue to be resoved in short order.

The lesson, as always, is this: anything you do that takes control of YOUR environment out of YOUR hands, to include the myopic Download and Install Updates Automatically should have “caveat emptor” written all over it beforehand and “I told you so” afterwards.

So, I recently had occasion to open up a browser-based Forms Services form from outside of the site collection where the template and the "Save Location" both reside…you know, kind of like one of those completely unplanned "Real World Scenarios" that we are always hearing about.

Anyway, anyone that has opened up a Forms Services form in the browser has noticed the extremely long URL that is necessary. For the uninitiated, here is a very quick synopsis of the various portions of the URL.

• Base URL. Forms Services forms are processed by an ASP.NET page located in the layouts folder. This is the base URL and it looks like this:
  • http://<<URL to your site>>/_layouts/FormServer.aspx
• Query String. There are various query string parameters that you may or may not have, depending on your situation.
  • XsnLocation. This is the location of your Form Template, and it looks something like what appears below. If you click on the "New" button in a document library configured to use the form, this parameter is NOT encoded, although the others are…it’s probably a good idea for you to encode all of them if you are building your own long-ass URL from scratch. For the sanity of anyone reading, I am not going to show encoded stuff here. If you would like a quick and easy way to encode/decode stuff, here is a good one.
    • XsnLocation=http://<<site>>/Form Templates/Template Name.xsn
  • Save Location. This is usually optional, as the form will just submit to the Document Library specified in the form template if this parameter is not there. Here is what it normally looks like:
    • SaveLocation=http://<<site>>/Documents
  • Source. This is the page you want to bring up after the user is done with the form…and is the source of the challenge I had that started this whole darn thing. Basically, if you try to pass a Source parameter that is from a different site collection, Forms Services will treat you like a pigeon treats a statue. Here is what this parameter looks like:
    • Source=http://<<site>>/Pages/Success.aspx
  • DefaultItemOpen. This parameter is used to force the form to open in a browser. If it is set to something other than ’1′ or not present, the form will try to open in InfoPath. Here is what the "open in browser" option looks like:
    • DefaultItemOpen=1
• The Whole Damn Thing. So, if you put all that stuff together, it looks something like this:
  • http://docs.company.com/sites/active/_layouts/FormServer.aspx?XsnLocation=http://docs.company.com/sites/active/Form Templates/Template Name.xsn&SaveLocation=http://docs.company.com/sites/active/Documents&Source=http://docs.company.com/sites/active/Documents/Forms/AllItems.aspx&DefaultItemOpen=1

So, I am not sure if you caught on to the main issue reading through all that junk, but here it is in a nutshell. If you try to pass in a "Source" parameter that is from a different site collection than the one where the template is located, Forms Services will barf. That kind of puts on damper on my "Real World" scenario of having the users access a centralized landing page / application, while exhibiting a higher level of control over the document processing center where the forms are going to be filled out.

I know what some of you might be thinking – just use a new window/tab. The problem with that is that not everyone likes popups, plus, sometimes you end up with a useless popup sitting there just displaying "The form has been closed" in the middle of the screen. Besides, popups are just so Web 1.0. Modal windows, that’s wave of the future, man!

For those of you that have seen SharePoint 2010 in action, you know Microsoft has gotten behind the whole modal window thing as well. In fact, if you have access to a SharePoint 2010 box, go ahead and type in the URL to the Upload form of one of your document libraries (http://<<site>>/Documents/Forms/Upload.aspx). SharePoint will get the standard Upload page from the _layouts folder, and it pretty much looks like a normal SharePoint page, right? Now, add in a query string parameter so it looks like this (http://<<site>>/Documents/Forms/Upload.aspx?IsDlg=1). See that? That form is damn sure ready for a modal dialog, huh? In fact, it is the standard way that Microsoft allows users to upload documents to a library, by putting the Upload form in a modal window and using the IsDlg parameter to keep all the extraneous stuff from showing up.

Well, that’s not the only place where Microsoft has bought into this whole modal window thing. As it turns out, there is a JavaScript method set up for this that comes along with the ECMAScript Class Library that you can use from just about any SharePoint page. Check out Jomit’s post that I referenced above for a little more detail and the links to learn more about the method and the ECMA library.

Since the FormsServer.aspx page doesn’t even recognize the IsDlg parameter, I didn’t even need it. So, armed with everyone’s favorite way to hack a SharePoint page (the Content Editor Web Part), I set out to get my InfoPath form to open up in a modal window. Here is the code that got it to work:

<script type="text/javascript">

//Handle the DialogCallback callback

function DialogCallback(dialogResult, returnValue)

{

}

//Open the Dialog

function OpenModalDialog(dlgURL)

{

var options = {

url: dlgURL,

width: 700,

height: 700,

dialogReturnValueCallback: DialogCallback

};

SP.UI.ModalDialog.showModalDialog(options);

}

</script>

//Link to InfoPath Form

<a href="javascript:OpenModalDialog(‘http://docs.company.com/sites/active/_layouts/FormServer.aspx?XsnLocation=http://docs.company.com/sites/active/Form%20Templates/Form%20Template.xsn&amp;SaveLocation=http%3A%2F%2Fdocs%2Ecompany%2Ecom%2Fsites%2Factive%2FDocuments&amp;DefaultItemOpen=1′);" onmouseover="javascript:window.status=”;return true;" onmousedown="javascript:window.status=”;return true;">Coolest Form Ever</a>

So, you see that I have gotten rid of the "Source" parameter in the Query String, as that still breaks the form if you send it something that is in a different site collection than the template, but the UX is about 100 times better than having a popup or (even worse) sending them to a page that is on a different site collection than where they started.

I still need to move this out of the CEWP before it is ready for prime time, but just think about the implications here. This is a bona fide slam dunk and a huge win for Microsoft by allowing us to quickly deliver solutions that are in line with what others are doing in the industry.