point-n-click

A man and a woman are playing golf.  They are playing on this old, rustic course and they come to this old barn on the side of this course. The guy hits the ball over there, and he goes over: Guy: You know,  I'm going to take a drop and just forget about the barn, just take the stroke penalty. Wife: Wait a minute, honey. What if you just open up the doors and hit right through?  You don't have to take the penalty.  So he hits the ball, and it ricochets off something and ricochets off something else, hits his wife in the head, kills her dead . One year later, the guy is playing the same course.  Comes to the same hole.  He is playing with a buddy of his.  He pushes the ball into almost the same place.  And he tells his buddy Guy: Hey man, I'm just going to pick it up and take the stroke penalty.   Buddy: Hey man, no, you know what you should do?  Open up the doors and hit it right through - then you won't have to take th...

The problem statement is in MOSS 2007, when the user adds custom content types to an existing document library and then set them up to appear in the new document dropdown, MOSS still uses the default Document content type (though after saving, you can edit properties to set the correct content type - how undesirable!). Stephen Muller pointed me in the right direction for a fix, but mine differs slightly from his. Solution: Create a document library and set the default Document Template to None . i.e. do not select Microsoft Word, Microsoft Office Word 97-2003 template, etc. After the document library is created, do this within the Document Library Settings: Create Column s or Add from existing site columns go Advanced Settings > Allow managment of Content Types=Yes,    then Add from existing site content types then Change new button order and default content type and set the new content type up as #1 (for example)

When building custom workflows, often we want custom Task edit screens as well.  A custom Task Content Type allows us to collect much deeper data than 'completed'.  However, since we are ditching the default Task edit pages, we lose a couple of useful features; a link to the underlying Workflow item as well as the implied context of the Task. Given the need to provide context to the user when overrriding the default task form, you may come across the desire to display some file information, custom columns/properties, links, etc on the task edit page.   To accomplish this, we need to gain two pieces of understanding: How and when to modify ASPX page elements from the code-behind c# class How to extract the underlying information from the Workflow's original item When: during the page_load() of inherited class; protected void Page_Load(object sender, EventArgs e) { if (!Page.IsPostBack) { ...

Two requests that are probably part of every SharePoint workflow design: Permit only the users who are assigned a WF tasks to edit (i.e. complete) them Record the user name of the person who completes a task (instead of the System Account) Not suprisingly, neither of these pretty simple, seemingly obvious design concepts can be done out of the box / without some customization.  Also, certain configuration screens might trick you into thinking you can do this directly within the SharePoint UI (you can't; more on this in the deeper blog posts). Part 1: Security of Workflow Tasks in SharePoint 2007 and Visual Studio 2008 Part 2: Audit Trail of Workflow Tasks in SharePoint 2007 and Visual Studio 2008   There are a couple of good blog sources for each of these customizations, but I didn't find any of them to be thoroughly detailed with screenshots, pitfalls, etc.  So what I hope to do in this two part blog post is cover some portions I think those...

Admittedly, I've been lazy about just dropping code into blogger (unformatted), but now I'm glad to say that I've finally gotten around to adding a bit of css and javascript magic into the blogger template. The syntax highlighter code is created and maintained by Alex Gorbatchev  and to get it up and running quickly, I more or less used Carter Cole 's instructional write up.  After modifying the theme choice and putting the css and js on a host, we are cooking with a Foreman!  Note, I'm using the standard distribution which includes a smaller set of brushes , whereas there are many more out there , and others in development. So here is exactly what I did: Download the current distribution of the sytnax highlighter above, or decide if you are okay with letting someone else host that css & javascript for you if chose to downloaded it, upload/ftp/host it at your own provider (e.g. I use 01solutions.com ) Log in to your blogger account ...

This topic is within a SharePoint 2007 workflow, how do we get the Workflow History to reflect the user who modified a task, rather than the "System Account".  I've successfully implemented the solution suggested by Julie Kramer , from the office dev blog.  Here we go: snippet of a workflow design in VS2008 - focus on the two red activities Assign a new field to the Executor property of the OnTaskChanged activity in question (you'll see this property in the property window on the activity). Note we use this new field in a later LogToHistoryListActivity's Method_Invoking() by assigning the UserID property of the LogToHistoryListActivity's object Add a userid lookup/helper function to guarantee a valid SharePoint user id is in place private SPUser GetUserObject(string accountID) { try { if (accountID.IndexOf(@"\") > 0) { SPUser use...