The fascinating thing about working with SharePoint is how new things continue to emerge. It’s like when you watch a movie for the 10th time and notice a scene for the first time. In my case, these always seem to be things I can’t do. If you read last week’s post, you know that I have been on a mission to tryto set up recurring calendar entries that are only visible for one or two weeks before their actual start date. We want to be able to preload a series of events but have them show up only proximate to their actual start dates. I was able to set the date range for the item to be visible, using two calculated columns and I was able to easily filter on that date range. Unfortunately, this doesn’t work with recurring items. Why not? Because a recurring item:
“Appears as a single master event on the All Events view, but as recurring instances on the Current Events and Calendar views.”
If you specify a calendar entry with a start date of June 1, 2010, set it as a monthly recurring item and have it repeat three times, the entry has a Start Date of 6/1/2010 and an EndDate of 9/1/2010. If you open the Calendar view or Current Items view, the series of events will appear to have start and end dates of 6/1, 7/1, 8/1 and 9/1, but the actual item in the All Items view will have a start date of 6/1 and an end date of 9/1. The recurrence instructions are stored in an XML attribute of the master item and are rendered by the Calendar and Current item views. I could render the XML too, but I was trying to do this without writing code. Click here to see Microsoft’s explanation of SharePoint calendar items for a better understanding of how this works.
Of course, storing the rendering instructions in a single item makes sense; otherwise, you could not edit the series. What I really needed was a way to “repeat” an item a certain number of times at a specified interval of days. That brought me closer to writing code, I wrote a Workflow in SharePoint Designer. In order to drive the workflow, I added two more columns to the Events list: RepeatTimes (integer) and RepeatDays (integer). I set the default for the RepeatTimes column to 0 and then added a workflow that does the following:
- If RepeatTimes is greater than 0
- Set Variable: NewStart to Events:Start Time
- then Add Events:RepeatDays to Variable:NewStart (Output toVarialble: NewStart)
- then Calculate Events:RepeatTimes minus 1 (Output to Variable:NewTimes)
- then Set Repeat Times = 0
- then Copy Item in Events to Events
- then Set Start Time to Variable:NewStart
- then Set Repeat Times to Variable:NewTimes
- then Set End Time to Variable:NewStart
- then Update item in Events
Notice, I am modifying the Current Item, saving (copying) it as a new item and then modifying the Current Item again and saving it. I chose this route for two reasons. First, I like decrementing values as opposed to incrementing them. Decrementing heads toward a self-inflicted end point of 0 since SharePoint doesn’t allow workflows to occur negative times. This is important since, even though I can work on a test server, I really can’t step through SharePoint Designer code like I can code in a development environment. The other reason I went this route is because SharePoint Designer makes it easier to reference the Current Item than it does the item(s) created by the copy operation. If I were writing code to solve this problem, I would create the new item, modify its attributes and save it. Of course, if I were writing code… Actually, “if I were writing code” is the topic of next week’s entry in this series, so let’s hold off on that for now.
Now, the question is: did I accomplish my goal? Well, according the people responding to the recent “what makes soemone a developer?” series on Twitter, yes I did. Most of those people seemed to agree that a SharePoint Designer solution is not code. I would certainly agree that SharePoint Designer is not a development environment, but I would argue that it is code. More importantly, since even the Calculated Column syntax I described in last week’s article is beyond the capability of most of my end users, I would say that I failed to solve this problem without code.
So the question becomes: “if I resorted to writing code, would it have been better to skip the extra columns, the calculated columns and the workflow and just program the solution directly?” I am going to preview next week’s article here and answer this question with a “No”. There is a benefit to solving this problem the way I solved it – somehow, it was all done in SharePoint.