Brad,

You are correct on the syntax change...must have type-o'd somewhere along the line.

I have updated the post.

Thanks,

- Dink

Manny,

Once I have time (the eternal struggle), I'm planning on a "Part 3" that covers the customizations that are needed to take in account for permissions and how to make it "appear" that the users can only register and not contribute to areas that we wouldn't want them to.

I've been meaning to get this done, just haven't had the time yet...but it will be coming, I promise :)

- dink

Todd,

Not directly...this template is designed to allow users to register themselves and not for others to register them.

You could probably add in this functionality though by seeing if you can create a custom workflow to handle adding in users to the registrations lists.

Not sure on the specifics of the WF, but that's where I'd suggest starting...although, it'd most likely have to be a custom Visual Studio WF since you'd have to deal with the user "context" problem - all activites in the template are based on the "current" user context, and WF's designed in SPD cannot run under the context of a different user other than the one that initiated the WF.

Hopefully that helps some,

- Dink

Scott,

You'll want to add it in as part of the URL in the section just before the closing quote (before the text "Remove").

Like this:

<a href="Lists/Registrations/Unregister.aspx?ID={../../../Registrations/Rows/Row[@Course_x0020_ID=$CourseID and contains(@Author, $UserID)]/@ID}&amp;Source=http://<Your page here>">Remove</a>

The "Your page here" section refers to where you want them taken after unregistering (as opposed to the "AllItems.aspx" page).

Also, dont include the "]" (bracket) in the page url.

Add it in as:

&amp;Source=http://your referring page

not:

&amp;Source=http://your referring page]

When I get a chance, I'll update this post to include this section.

- Dink

Iain and Bill,

Couple of things to look at:

1. What errors (if any) are you seeing when trying to unregister?

2. Verify that have modified the "Remove" link xsl to include the changes I mention in this article.

3. Does the url change when hovering over the "Remove" link?  The "ID" portion of the url should be different for each "Remove" link.

Example:

/Lists/Registrations/Unregister.aspx?ID=3

/Lists/Registrations/Unregister.aspx?ID=4

/Lists/Registrations/Unregister.aspx?ID=5

If not, go back and redo the xsl.

4. Did you also update the workflow detailed in "Part 1"?

5. Verify that have setup permissions correctly based on the details listed in "Part 3".

I'm sure it's something simple that causing the issue for each of you.  I've set up sites based on the template many times for my users and the one thing I know is that if you accidentally skip something along the way, that little thing will come back to bite you.

The best advice I can suggest is to start from scratch and re-deploy the template, then work through the customization steps slowly and carefully to make sure that you dont skip anything.

I realize that this is frustrating, believe me.  It took me a long time to collect all of the information I've written about in these three articles in order to make this template "functional".  I just with they would have released it with these (and other obvious suggested fixes) already implemented.

- Dink

Iain,

All you need to do in order to test this is the following ( I just did this myself about two minutes ago):

Create site from template.

Add 2 new courses: "Course1" and "Course2".

Open the "Courses I am attending" webpart and open its "XSL Editor".

Copy/paste its contents into notepad and search for the text "Remove".

Replace the entire cell it resides in with the updated html:

Old:

<td class="ms-vb">

   <a href="Lists/Registrations/Unregister.aspx?ID={../../../Registrations/Rows/Row/@ID}">Remove</a>

</td>

New:

<td class="ms-vb">

   <xsl:variable name="CourseID" select="@ID"/>

   <a href="Lists/Registrations/Unregister.aspx?ID={../../../Registrations/Rows/Row[@Course_x0020_ID=$CourseID and contains(@Author, $UserID)]/@ID}">Remove</a>

</td>

Register for the two courses you created then try unregistering for one of them.  

Clicking the "Remove" link should take you to the confirmation screen to unregister and after clicking "OK" on that screen, you should be redirected to the "Registrations" list that will display any current registrations - your item should either be processing the "Unregistration" workflow, or already have completed.

Going back to the home page, the "Courses I am attending" webpart should now only display the courses you're currently registered for (or be blank if you had only registered for one course earlier).

All of this is done from the OOTB template with only making the single modification to the XSL - at this point it should be working.

The remainder of the "Fixes" will take care of updating the seat count, etc. (including setting custom permissions in step3 as you mentioned).

And, you are correct in the difference in what I have posted in the article as opposed to what is in the XSL in the default template.  I think its was because I had some other customizations in mine (been a long time since then).  Just use the above steps as it should be accurate.

Try the above steps and post back with your results.

- Dink

(Also, "pay" is not neccessary...this is a community blog, and although I dont post articles near as often as I'd like to, this is all in an effort to help out those that need it...plus I just dont have the time to take on new projects outside of my normal work)

Iain,

I'm not sure what else could be the problem in this case.  Each time I've tested by starting over (new site collection, fresh download of the template, new site created from the template), all I've had to do is just perform the steps I detailed in order to get the "Remove" portion to work.

You might want to open the site through SPD and verify that the workflows exist (no workflows = no removal).  Also, what's the "context" in which you're running the site?  Are you accessing it as an administrator?  (might as well try with server farm permissions - start with highest level, then work your way down from that to see if its a permissions thing).

The only other thing I could suggest (although I'd hate having to do this myself) would be to create the functionality of the site yourself by following the template creator's walkthrough series on msdn.blogs

Part 1: blogs.msdn.com/.../training-site-template-part-1-introduction.aspx

Part 2: blogs.msdn.com/.../training-site-template-part-2-workflows.aspx

Part 3: blogs.msdn.com/.../training-site-template-part-3-custom-views-and-forms.aspx

I know its a bit of a pain to have to duplicate it, but that might be the last resort if you cant get it to work by any other method.

I'll think about it some more as well to see if I can come up with anything else for you to check...I'll post back if I can find anything.

Sorry I couldn't help more,

- Dink

Iain,

Unfortunately, it wouldn't work if I tried to save it as a template for you.

The way that SPD workflows work is that they are not attached to an individual list template, rather they get attached to a list "Instance".  Because of this, they aren't really "Portable" in the same sense that list "templates" are.  Saving a site that has SPD workflows attached as a template, will not include the workflows.

Having said that however, there is a kind of "hack" that you can use to lessen the time it takes to re-create workflows from list to list (or site to site).

See this: nickgrattan.wordpress.com/.../applying-a-sharepoint-designer-workflow-to-multiple-lists

And this: www.sharepointblogs.com/.../reparenting-a-workflow-to-a-different-list.aspx

For options of copying over workflows piece-by-piece.  The only issues I've had in these approaches is that you'll have to go back in and re-associate some of the variables and fields in the workflow due to the GUID change of moving from one list/site to another.  Still doesn't take too long, but you'll need to know this if you want to go this route.

Also, just to cover all bases - I re-downloaded the template from MS this afternoon and deployed it to a new farm.  Once uploaded, I went through the customization steps I listed out in Part 1 and Part 2.  After performing these, the site worked as it should with the unregistration process functioning fine.

I've tried this in WSS 3.0 and in MOSS2007, each with no service packs installed, and each with SP1 and SP2 installed (6 different configurations) and it worked fine each time.

Not sure what else to tell you.

- Dink

Iain,

Good to hear you got it working now.

- Dink