Working with WSS, I use a lot of simple workflows that are created in SharePoint Designer. Quick and easy creation, deploying and maintaining in normal scenarios. BUT:

Suddenly on my development environment, the workflows where giving following error message: "You do not have permission to do this operation. Ask your Web site administrator to change your permissions and then try again, or log on with a user account that has this permission. To log on with a different user account click OK. " I really had to look hard for a solution. At first I tried everything I could to ensure the users I was using had sufficient rigths. It appeared it had nothing to do with the users I was using. These are the symptoms I was hving:

• When I tried to save a workflow in SharePoint designer after I checked the options: Automatically start this workflow when item is created or changed I got this error: "You do not have permission to do this operation. Ask your Web site administrator to change your permissions and then try again, or log on with a user account that has this permission. To log on with a different user account click OK. "
• When I tried to run a workflow manually I got an access denied error.

Googling didn't helped me a lot until I ended up here: http://kbalertz.com/947284/declarative-workflow-start-automatically-after-install-Windows-SharePoint-Services-Service.aspx

I set my application pool to run under the system account and then everything worked again. The reason why I started looking there was because on every web application on the server I had the same problems. It's strange that the sites kept on working but only the workflows had problems. After I changed the account for the application pool in the SharePoint administration website, I did a IISRESET /NOFORCE command.

Here's an article of Microsoft about this error: http://support.microsoft.com/kb/289335. The proposed solution could work in some cases, not in this case obviously!

I thought this was a often used functionality of WSS, but when I started googling I guess I was wrong.

I needed to add some custom action to the list items in my document list. Sharepoint made this very easy to do. This article describes it pretty good: http://msdn.microsoft.com/en-us/library/ms473643.aspx.

I followed the example, only using this custom action: UserInterfaceCustomActions.ECBItemToolbar. This is the one that is shown in the action toolbar of an item. Here is the result:

Copy to public.

As I was following this example I noticed that when I tried to install the feature there was an error in the XML:

Feature definition with Id 2aeaccad-cf77-4d38-86a2-4fca58bbc0cc failed validation, file 'UICustomActions.xml', line 8, character 5:
The 'Type' attribute is not declared.

This is how it looked like at the Microsoft site:

<!-- Per Item Dropdown (ECB)-->  

<CustomAction     

 Id="UserInterfaceCustomActions.ECBItemToolbar"    

 RegistrationType="List"    

 RegistrationId="101"    

 Type="ECBItem"     

 Location="EditControlBlock"    

 Sequence="106"    

 Title="Copy to public">    

 <UrlAction Url="/_layouts/CustomActions.aspx?ECBItem"/>  

</CustomAction>

This is how it should look like:

<!-- Per Item Dropdown (ECB)-->  

<CustomAction     

 Id="UserInterfaceCustomActions.ECBItemToolbar"   

 RegistrationType="List"    

 RegistrationId="101"    

 Location="EditControlBlock"    

 Sequence="106"    

 Title="MY ECB ITEM">    

 <UrlAction Url="/_layouts/CustomActionsHello.aspx?ECBItem"/>  

</CustomAction>

The Type attribute is not allowed. Get rid of the "Type" attribute and it will work, strange that Microsoft has this in their example. When you want to deploy the item to all type of list on the website, remove the RegistrationId attribute. For a custom list type the registrationId = "100".  RegistrationId="101" is for document libraries.

You can find a list of all attributes for the custom action element here: http://msdn.microsoft.com/en-us/library/ms460194.aspx.

After I installed and activated the feature, I needed to restart IIS and it worked. Then I made some changes to the XML and wanted to update the feature. Here is the command to do that:

stsadm -o installfeature -filename UserInterfaceCustomActions\feature.xml -force 

Followed by an iisreset everytime you made changes.

So it very easy to do this. You can use a webpart page in combination with custom webparts to handle the action. I will keep on developing in this area, you can expext more info later.

When you would like to install different features for different sites, create as many directories in the Features dirrectory as you like. I used UserInterfaceCustomActions as directory like the example, but this is not a mandatory name, when you start developing, choose the names of these directories wisely, so you can distinguish the features. E.g. MyCompanyTaskManagement\Feature.xml and MyCompanyFinance\Features.xml. This way we instantly know what the features are for.

As I was deploying the first features to test sites, I noticed that I only could deploy to the entire site collection. If I tried to deploy to a subsite I got this error: The specified feature applies to the entire site collection, but the specified URL refers to a particular sub site.  To apply this feature to the entire site collection, use the root URL ...  At first I couldn't find the problem, because I was trusting on the example on the Microsoft site. But for the second time I noticed there was an error in their example. In the feature.xml they put Site as scope:

<?xml version="1.0" encoding="utf-8" ?>

<Feature Id="6FA98D7A-D802-4f30-8473-0F9B00DD8F7C"

     Title="UI Custom Actions"

    Description="Custom action on list items."

    Version="1.0.0.0"

    Scope="Site"

    xmlns="http://schemas.microsoft.com/sharepoint/">

  <ElementManifests>

    <ElementManifest Location="CustomActions.xml" />

  </ElementManifests>

</Feature>

Then they suggest this for the activation of the feature:

stsadm -o activatefeature -filename UserInterfaceCustomActions\feature.xml -url http://Server/Site/Subsite

Which is not correct, because if they use Site as scope, it is not permitted to activate it to a subsite, but it is required to activate it on site collection level. So the solution to this problem is: Use scope="Web" in the feature.xml. Then it is allowed to activate it for a subsite!

You can find the scopes and more on the feature.xml file here.

When you need security on your feature, its really easy. Just add the Rights to the custom action XML. The list of all the rights you can use can be found here.I used the AddListItems to make sure only users with sufficient rights could view the feature. Here's the example of the XML:

<?xml version="1.0" encoding="utf-8" ?>

<Elements xmlns="http://schemas.microsoft.com/sharepoint/">

  <CustomAction

    Id="UserInterfaceCustomActions.ECBItemToolbar"

    RegistrationType="List"

    RegistrationId="100"

    ImageUrl = "/_layouts/images/WRI16.GIF"

    Location="EditControlBlock"

    Sequence="106"

    Title="Add progress">

    <UrlAction Url="serverurl/TM/default.aspx?qID={ItemId}"/>

  </CustomAction>

  <CustomAction

    Id="UserInterfaceCustomActions.ECBItemToolbar"

    RegistrationType="List"

    RegistrationId="100"

    ImageUrl = "/_layouts/images/EML16.GIF"

    Location="EditControlBlock"

    Sequence="106"

    Rights="AddListItems"

    Title="Send alert">

    <UrlAction Url="serverurl/TM/default.aspx?qMailID={ItemId}"/>

  </CustomAction>

</Elements>

Here's a quick list of all Rights you can use for a feature:

AddAndCustomizePages
AddDelPrivateWebParts
AddListItems
ApplyStyleSheets
ApplyThemeAndBorder
ApproveItems
BrowseDirectories
BrowseUserInfo
CancelCheckout
CreateAlerts
CreateGroups
CreateSSCSite
DeleteListItems
DeleteVersions
EditListItems
EditMyUserInfo
EmptyMask
EnumeratePermissions
FullMask
ManageAlerts
ManageLists
ManagePermissions
ManagePersonalViews
ManageSubwebs
ManageWeb
Open
OpenItems
UpdatePersonalWebParts
UseClientIntegration
UseRemoteAPIs
ViewFormPages
ViewListItems
ViewPages
ViewUsageData
ViewVersions

In WSS 3.0 you can add a person or group field. In this field, it is only possible to insert 1 person or group. But sometimes we need to insert several users or groups. I started to google and ended up on this Microsoft blog.

I started to try the proposed solutions, but I keep getting the message: You are only allowed to enter one item. The proposed solution involved changing the CAML of the field type in the list. It had to look something like this:

<Field Id="{8ADC8169-6BA9-4d7e-B77D-B0F8B79BBEC5}"

 Name="Author" 

 BaseType="Text"

 DisplayName="Vertreter"

 Type="UserMulti"

 Sealed="TRUE" 

 ShowInDisplayForm="TRUE"

 ShowInEditForm="TRUE"

 ShowInNewForm="TRUE"

 ShowInListSettings="TRUE"

 DisplayNameSrcField="Account" 

 List="UserInfo"UserSelectionMode="PeopleOnly"

 SourceID="http://schemas.microsoft.com/sharepoint/v3"/>

I tried this, but it just didn't worked. The field looked like this:

But then something strange happened. When I added a new field, the option allow multiple selections appeared. At first site, it seems that setting a field of type user to usermulti manually in the DB made the change. Now the field looks like this:

So now WSS allows it to use multiple persons or groups in 1 field. Don't ask me how it got there. I think it is because I changed the CAML manually and then WSS enabled it for all fields? Maybe someone has a better explanation for this. I reproduced it, so it works fine now.

* remark: When I choose allow multiple selection I get this message:

Earlier versions of client programs might not support a Person or Group field that allows multiple selections. Adding this field might block those programs from saving documents to this library. 

The first consequence of this error already showed up. In the workflow in Sharepoint Designer I cannot see this field. In my case it makes it useless. So I will have to find a workaround or solution to this problem.

Don't start with the System.Net.Mail namespace, because Sharepoint has a better way to do this:

using Microsoft.SharePoint.Utilities;

SPUtility.SendEmail(SPContext.Current.Web, false, false, EmailTO, 

"SOP review request", message.ToString());

I made some webparts that are using htmlbuttons to perform some actions. At first I kept the ugly default button style. But when I found some spare time I start looking for some nice CSS classes to put on my buttons. I chose to use style of SharePoint itself, making sure the buttons will change their looks when I change the theme.

Here is the result of which I'm very pleased.

Before:

After:

The Yes button is the hoover style, the No button is the normal style. The colors used are the same as the Tab on top. Here's the code from my webpart:

_myNoReview = new HtmlButton();

_myNoReview.InnerText = "Yes";

_myNoReview.Attributes.Add("class", "ms-SPButton ms-WPAddButton");

_myNoReview.Attributes.Add("onmouseover", "this.className='ms-SPButton 

ms-WPAddButton ms-WPAddButtonHover';");

_myNoReview.Attributes.Add("onmouseout", "this.className='ms-SPButton ms-WPAddButton';");

_myNoReview.ServerClick += new EventHandler(_mybutton_click);

Controls.Add(_myNoReview);