SharePoint Blog Category Pagination

Quick and easy.  That is what it sounded like.

It’s Friday about 3pm, a department manager wants ‘something’ added in his department site.  They want to post information for another group to view.  They want to categorize the content so the users can easily sort through the various postings.  They wanted a blog.  For the sake of brevity I won’t go into more details on what, why, etc. related to the choices, just the interesting tidbits.

I quickly created a SharePoint Blog site under their SP 2007 department site, did the few obligatory things to make it nicer and fit the theme and the department and let it go.    The department manager was happy, the end.

4-ish pm – he is back. Gee, we notice that when we select a Category from the QuickLaunch and the posts display, there is this little “1-10 >” thing down on the very bottom…and we don’t like it.  We want to see everything posted in that Category on one page, we don’t care how long it is or if we have to scroll down for days.

OK, I will take a look…there must be a setting in the Blog settings somewhere.  Nope, can’t find it anywhere.

I look at the page, it is … Lists/Categories/Category.aspx, so I decide to open it up in SharePoint Designer (SPD).  If I try to modify the view in ‘design’ mode it hangs SPD.  Nice touch. Did I mention it was late Friday afternoon?  After much searching around in Code mode, I find what I am looking for – that is the tidbit controlling pagination.  I knew it had to be a page or item view limit somewhere in there. 

Here is what you do to adjust pagination:

Go and find the <ListViewXML> tag (in the Category.aspx or other page where pagination control is desired), search there for the section of code that looks something like this:

/Query><RowLimit Paged="TRUE">10</RowLimit><

Notice that “Paged” is equal to TRUE and has a value of “10″.  You can set the value to whatever number of blog posts you want to display.  I suspect that you could just set “Paged” to “FALSE” if you want to display every post from any chosen Category.  I plan to try that out very soon…but the critical knowledge has been gained and shared.

Enjoy your SharePoint Blogs!

UPDATE: I tested out setting Paged to “False”, which works fine, as long as you remove the number from the RowLimit (example above displays “10”).  If you leave a number in there, SharePoint will display that number of posts without pagination at the bottom to get to the additional posts.  Your code should look something like this:

/Query><RowLimit Paged="FALSE"></RowLimit><

Advertisement

SP Designer Forms – View, Update

A new request came in recently. A department wanted a form that anyone could use to submit suggestions.  They want the form to update a list so the suggestions could be tracked. Oh, the suggestions will need to be reviewed by the “boss” so he can approve any work that might be needed to implement the suggestion.  Oh yeah, before the boss looks at these there should be a designated reviewer to filter some of the suggestions so the boss doesn’t have to see duplicates or things that are simply inappropriate for this suggestion pool.

Doesn’t sound tough.

By the way, they also want an email notification when a new suggestion comes in so the “reviewer” knows she has to go check the list.  It would be nice if the reviewer didn’t have to “mess” with the SharePoint list, just see only what needs her review. Also, she needs to indicate (somehow) that the boss has things to review, since he doesn’t want to see every suggestion as they come in. He does want a reminder, via email, every now and then after a few suggestions have collected in the pool (list). Of course he only wants to see the items that the reviewer has already filtered through, none of the rejections.

Once the boss decides that the suggestion is worthy and approves it, he also may have some comments or directives, and he may want to route it to some other department. If the suggestion is ‘approved’ and work needs to be done, then we should have a place to track some notes on this item, and a status to track the item through the whole process.

Still not to difficult for SharePoint.

My thoughts ranged from standard approval workflow to custom InfoPath forms. But I chose to use SharePoint Designer (SPD) to create a series of forms based on a custom list. Why? One reason is because the users don’t really want to interact with a SharePoint List. Another is because there is a good chance that they need a list and not a form library (I can’t go into all of the details here). And the final reason for the purpose of this blog is “just because”. I won’t go into the entire setup, today, but I do want to get one important gem posted that may be helpful to others.

That gem is:

You can create the form based on the custom list, and set some of the fields to display as text, so that your reviewer cannot change those columns in the list. They only update the columns you want them to update, and can’t mess with the other columns (from the form).  This relies on the laziness of your users…if they want to go find the list there is nothing stopping them.   [side-note: I generally hide the list from the Quick Launch and provide easy to find links to the forms.]

How do you do this?

1. After inserting your chosen columns from the data source, right-click on a column in SPD in Design view.  The Common xsl:value-of Tasks window pops up (it may also display as “Common FormField Tasks”).  It should display the Data Field and Format as options.
   

   Inserted Column Form Properties

2. For the columns you want to display and not allow editing, select Rich Text in the Format as option.  (that is, change it from “List form field” to “Text” or “Rich Text”)
3. Save your form and test.  It should now display the columns as un-editable text while other columns in that item row remain editable.

Another “nice” thing to do in your form, if you are using Multiple Item views, is to alternate shading the item rows to make them easier on the eyes.  Use Conditional Formatting and apply the style when the Row Number is Odd (or even if you prefer).

Overview of how I accomplished the desired behavior:

1. Create a custom list with the necessary columns for the primary purpose and the management of this process
2. Create SPD forms for:
   • Submitting a suggestion
   • Reviewing suggestions
   • Approving suggestions
   • User viewing of “active” suggestions
3. Create a workflow to notify “reviewers” when new suggestions are submitted
4. Create a button for “reviewers” to click when they want the boss to be notified that it is time to look at the suggestions (SPD form button sends the email)

Calendar Reminder (Part 2)

In Poor Folks Calendar Reminder (Part 1) the problem, the request, the plan of attack, and the first step in building a reminder behavior in a SharePoint 2007 calendar was covered.  This post is the final installment on this topic.

Building Steps – People

Since each calendar due date/event could have a different set of people to notify, I decided that my initial implementation of this would be simple.  I kept it simple by using a plain multi-line text field in the calendar list to capture the email addresses of the desired recipients.  So in addition to the List Fields mentioned last time, I also created the following column:

ReminderEmail – Multiple lines of text, not required, 6 lines for editing, Plain text

In the future I may make a modification to improve this feature of the reminder depending on how the email is really used.  For your reviewing pleasure, here is what my columns look like:

Reminder Columns added to Calendar List

Building Steps – Workflow 1

My workflow has four steps, each described below.   To build this workflow:

1. Launch SPD (SharePoint Designer)
2. Open your site
3. Select File, New, Workflow
4. In the Workflow Designer window, Name your workflow (default is Workflow 1)
5. Select the Calendar list that has the “reminder” columns added
6. Check the Automatically start this workflow when a new item is created check-box
7. Keep the check in the Allow this workflow to be manually started from an item check-box
8. Click Next

Before we start creating Step 1, I want to add some Initiation Parameters.  I will explain why, and it will be more apparent why later, so for now just click on the Initiation… button, we will add two parameters:

1. In the Workflow Initiation Parameters window click the Add… button
2. Field Name: ResetDate
3. Information Type:  Choice (menu to choose from)
4. Click Next
5. Enter the Choices: “No” and “Yes”
6. Default value: No
7. Display as: Radio buttons
8. Click Finish
9. Click Add…
10. Field Name: TempDateTime (I chose this name to avoid any possible conflict with other variables, functions, reserved words, etc)
11. Information Type: Date and Time
12. Next
13. Select the Use date and time item creation as default or Blank default value radio button
14. Display format: Date and time
15. Click Finish
16. Click OK to save the Initiation Parameters and close the Workflow Initiation Parameters window

Workflow Initiation Parameters

Step 1 – Check Reminder, Set Variables

Step 1 will have 4 Conditional Branch’s :

Conditions: select Compare Calendar field, then select the Reminder field in the Current item and set it equal to “No”

select Compare any data source, then select Workflow Data and the Field Initiation:ResetDate, set it equal to “No”

Actions:

select Set Field in Current Item then select the ReminderStatus field to “No Reminder Set”

select Log to History List, enter “ReminderStatus Set to No Reminder Set”

select Stop Workflow, enter “No Reminder Requested”

This first condition checks to see if the user chose to send a reminder for the event/calendar item.  If they did not (No value in the Reminder column) then we want to note that in the ReminderStatus column, log it in the workflow history and Stop the workflow.  The default for our Initiation Parameter ResetDate is No, so our workflow would stop here if the workflow automatically started on a newly created item and the user selected not to send a reminder.

For the remaining Conditions, I will assume you can select the correct components to insert and simply show you the end result.

Workflow Step 1

Conditions: Else if Reminder equals Yes

and Initiation: ResetDate equals Yes

Actions:

Log “Reminder Requested” to the workflow history list

then set ReminderStatus to Waiting
then set ReminderDate to Initiation:TempDateTime
then Log “Set Status to Waiting, Set ReminderDate” to the workflow history list

Conditions: Else if Reminder equals No

and Initiation: ResetDate equals Yes

Actions:

Log “Reminder Requested Manually” to the workflow history list

then set ReminderStatus to Waiting
then set ReminderDate to Initiation:TempDateTime
then Log “Set Status to Waiting, Manual ReminderDate” to the workflow history list

Conditions: Else if Reminder equals Yes

and Initiation: ResetDate equals No

Actions:

Log “Reminder Requested” to the workflow history list

then set ReminderStatus to Waiting
then Log “Set Status to Waiting,Using Item ReminderDate” to the workflow history list

Step 2 – Pause Using Days

This step handles the user option of selecting the number of days prior to the event that the reminder should be sent.  This step contains the same number of Conditional Branch’s as you determine.  Mine contains 6 because I provide 6 options to the user (0,1,2,3,4,7) however I will only present a few here, the same concept applies to each that you repeat.

Conditions: If ReminderDays equals 0

Actions: Log ReminderDays is 0 to the workflow history list

If the user hasn’t selected a number of days, and the default is 0 then we want to make note of it, but continue on.

Conditions: Else if ReminderDays equals 1

Actions:

Add -1 days to Calendar:Start Time (Output to Variable:date1)

then Log “1 Day Reminder – Pausing Until:” to the workflow history list

then Log Variable:date1 to the workflow history list

then Pause until Variable:date1

Conditions: Else if ReminderDays equals 2

Actions:

Add -2 days to Calendar:Start Time (Output to Variable:date2)

then Log “2 Day Reminder – Pausing Until:” to the workflow history list

then Log Variable:date2 to the workflow history list

then Pause until Variable:date2

For each of your options simply subtract the number of days found in the ReminderDays column of the current item.

Workflow Step 2

Step 3 – Pause Using Date

This step handles the user option of sending the reminder on a specific date.  It only contains one Conditional Branch:

Conditions: If ReminderDays equals 0

and ReminderDate is greater than or equal to Today

Actions:

Log Pausing Until Date: to the workflow history list

then Log Calendar:ReminderDate to the workflow history list

then Pause until Calendar:ReminderDate

Workflow Step 3

Step 4 – Send Reminder

The final step in our workflow simply checks to see that we are actually supposed to send a reminder, so one Conditional Branch handles it all:

Conditions: If Reminder equals Yes

Actions:

then Log “Sending Reminder to:” to the workflow history list

then Log Calendar:ReminderEmail to the workflow history list

then Set Variable:EmailAddresses to Calendar:ReminderEmail (this allows us to use the variable in the actual email To field)

then Email Variable:EmailAddresses

then Log “Email Sent – Ending Normally” to the workflow history list

Final Discussion

So what does our new workflow do?  We collect the options the user selected when creating the Calendar item in our new columns, and use that to determine how to Pause the workflow until the correct amount of time has passed.  Then we simply pause for that time and send the email with the desired reminder text.

Why we have the Initiation Parameters should be more apparent to you now.  If the user wants to run this workflow manually because they didn’t set a reminder originally or if they want to send another reminder our workflow would run and stop without sending the reminder email without these parameters.  By asking for the two parameters when running manually we give the user the option to kick off the workflow and adjust the reminder date or add a reminder date for that instance of the workflow.   You can see how I use this in Step 1 to update the ReminderDate column and use that date to pause and send the email reminder.

Poor Folk’s Calendar Reminder (part 1)

I received a request from a small department that has a (MOSS 2007) site on one of our SharePoint portals.  The group is an accounting group who, like most accounting groups, has a calendar full of due dates for various accounting activity.  There are a handful of those due dates which are for accountants in other locations to submit something back to this accounting group.   The accounting group establishes these due dates and enters them on this one specific SharePoint calendar.

The Problem

Although everyone involved in this process has access to the calendar, most of the remote accountants do not regulary visit the calendar.  They call and ask when something is due.  Often they don’t call, someone in the local accounting group has to call them looking for something that was due today or yesterday.

The Request

Allow the user creating the calendar item to mark it for reminders and define who should receive the reminders for each event.

Discussion

This is a sore spot for me.  Microsoft obviously knows how to enable reminders on calendars, it has been around in Outlook for a very long time.   They really should have enabled reminders in SharePoint calendars without having to fully integrate with Outlook…and in my opinion, should have enabled the features requested above as part of the base SharePoint calendar feature set.

Additionally, I know there are several very good third-party tools to accomplish this.  I also know there are numerous methods to accomplish this with some custom coding.  However, as the title of this indicates, this is one possible method which I was able to implement at no cost and doesn’t require me to tap our understaffed, overworked and highly paid developers.

I am happy to hear any and all comments, improvements, or arguments about my implementation, I believe in continuous improvement.

The Poor Folk’s Solution

After reviewing several good blogs related to this topic of setting up reminders using a workflow, I came up with the following for my solution.  Relatively easy to implement, easy to use, and flexible enough to allow some notification options for the users.  Primary requirement was to meet the basic needs of the users.

Plan of attack – Overview of solution

My workflow is actually very simple from a flow-chart point of view.  I have 4 steps, the first checks to see if a ‘reminder’ flag is set, if it isn’t the workflow stops.  The second step checks selections made by the creator of the event, sets variables, and pauses for a pre-determined amount of time – if the user chose to remind a certain number of days prior to the event.  The third step checks for a specific date reminder and pauses until that date – if that is what the user chose.  The fourth step verifies the flag after the pause and sends the email notification.

My concept evolved during the implementation of this solution.  At first I made the user select a specific date that they wanted the reminder email sent out.  This wasn’t very flexible and required the user to calculate out the dates themselves.  After talking with the primary users, I learned that they had a short list of possiblities that they expected.  The would want to set reminders 1, 2, 3, 4 or 7 days in advance of the event.  Why not just let them chose one of these options.  Since I already set up the “reminder date” column in the list from my starting concept, I decided to keep it and allow additional flexibility.  The user could then either choose a specific date for the reminder or select one of the predetermined options.

Building Steps – List Fields

I added the following fields to the Calendar list:

Reminder – This is a Yes/No column (actually setup as a Choice column with Yes/No options)

ReminderDate – This is a Date and Time column

ReminderDays – This is a Choice column, with choices of “0,1,2,3,4,7” and a default of 0

I also added ReminderStatus as a Single line of text column so that I could update it from within the workflow to provide some status information right in the calendar list (I create a standard view displaying these fields rather than the standard calendar view).  You may not want this, so consider it an optional field.

These fields need to be created first so that they are available to SharePoint Designer when creating the workflow.

Next Time:
Building Steps – People

Building Steps – Workflow 1

Calendar Reminder (Part 2)

Using alternate list data in a SPD Workflow.

Background:  MOSS 2007, SharePoint Designer 2007 used to create the workflow.

I have a user request workflow which is initiated when a new item is created in a user request list.  The user is required to select a ‘location’ when submitting the form (this form is used by many different locations in the USA).  Depending on the type of request an approval may be needed and I send an email to a designated approver based on the location that was selected by the user.   The user doesn’t know who the approver is and the support desk staff may or may not know either.  I currently am using hard-coded email addresses for the approvers in my workflow.  I ‘set’ a column with the email address once it is determined in the workflow and in later steps use that field in the email message.

What I would like to do is use another list to allow us to maintain the approvers, their appropriate email address, and the location where they are allowed to approve requests.

Here is how I did it:

1. Edit my workflow in SharePoint Designer (SPD)
2. Navigate to the appropriate step and conditional branch.
3. Modify the “Set” field line,  selecting my  ‘other list’ as Source in the “Lookup Details” section of the Define Workflow Lookup window (note that this window opens when you select another list in the Source drop-down).
4. Select the field in that source that I want used in the user request list for the Field selection of the Lookup Details section.
5. Under “Find the List Item” section, I used the other list Location column in the Field selection.
6. I then used the current list Location in the Value selection
7. Click OK to close the Define Workflow Lookup window.
8. Click YES to the warning (if it displays) that says “The lookup that you defined is not guaranteed to return a single value.” etc.. “Do you want to continue?”
9. Finish your workflow to save and close the Workflow Designer window.
10. Test it out – The appropriate approver is pulled from my “approval maintenance” list and placed into the current list item in my user request list!

This took me a little effort to figure out, it isn’t clearly documented and I couldn’t find it in the SPD help.  Maybe someone else will be able to use this, and shortcut their search effort to figure out how to do this kind of lookup in a workflow.

Change List in Designer Form

Recently I created a request form in SharePoint Designer 2007 which was to be used to create a new item in a SharePoint List on one of  my MOSS 2007 sites.  I worked to get the appropriate look and feel, layout, etc. on the form so that the form would be pleasing to the users.  Normal stuff, right?

Then I tested my form out.  Worked great, so I added a 3-state workflow to the list.

This workflow needed to simply notify someone when the first step occurred: after a user submitted the form, creating the new list item.  For this step I thought it would be nice if the user got an email automatically, telling them we recieved their request.   To accomplish this I wanted to use OOTB tools, so I simply selected the CreatedBy  for my Task Assigned To selection in the Task Details within my worklfow.  This allowed me to check the Include Task Assigned To checkbox under E-mail Message Details.  In the Body I placed a nice and friendly message to the user saying we got the request.  Dandy, this is quick and easy.

Not so much.

The first thing testing brought to light was that the URL link included in the email was broken.  My list name contained a space and the automatically generated url in the email stopped at the space, with the remainder of the url following the link in plain text.  Users would have to copy and paste the whole url in the browser to go check the list.   Since they might want to look at the status of the request by going to the list, I felt this needed to be remedied.

Hey, Change the list name…Settings, List Settings, Title, description and navigation.  Won’t work.  The name will appear to the user but the url stays the same.

Ok, just create a new list with a name that doesn’t have spaces.  I saved the list as a template, created a new list using the template and now we have a list that won’t generate a broken URL.  Solved.

Wrong.  Of course the Form is using the original list.  I searched to learn how to detach the list in Designer.   You may have better luck than me, but I couldn’t find a way to do it.  It would have been nice of Microsoft to include the capability for swapping out one list for another on a form, but they didn’t.  Or if they didn’t they didn’t make it easy to find.  I know, I know there would likely be column differences which would require some management and resolution.  Still, it seems like this would be used by more than me and more than once.

I finally went to the code and changed the List ID from the old list to the new list’s ID using Replace in Designer.  This worked fine.  Now my effort on the form didn’t have to be repeated just because I needed to change the name of the list.

Testing proved my point…but another issue came up.  Now my user is getting email’s from the Workflow Tasks list as well.  Since they are the Assigned To person for the task, they get an email…and wonder what task they have to complete.  So I have to modify the workflow to stop using Created By as the Assigned To in the Workflow Task.  That is easy enough, but now I am back at square one.  I still want to generate an email to the requestor, but that will wait until tomorrow.  🙂