Normally, if I were having K2 BlackPearl on the same box as SharePoint, I would install SharePoint first, then K2. This seems to work without much fuss, and is the right way of doing it.

However, this time I had installed K2, and was now trying to install SharePoint (long story). However, SharePoint’s installer kept failing (using the SP2 with cumumlative updates to April, in a slipstream installer). It simply would not complete successfully.

Eventually, we tracked this down to the SQL 2005 Report Viewer. We uninstalled (via ‘Add an Remove Progams’) the ‘Microsoft Report Viewer Redistributable 2005′ program, stopped the K2 BlackPearl service, and tried installing SharePoint again. It worked.

Of course, the idea would be, don’t have the two on the same box. But just in case someone else tries the same thing.

And I hope I’ll get back to development soon.

We’ve seen:

• That listing users is fairly simple using some ‘magic values’, but that supporting the ‘View Selector’ is a bit more complex!
• That resolving the MembershipGroupId GET parameter is important, but pretty simple, and that there are many ways you could choose to do this.
• That adding users is pretty simple too – it’s just the sort of SharePoint API code you’d get asked about in the WSS3 App Dev exam.
• That removing users is a bit yucky – JavaScript to get the IDs of selected users – but again, the code itself is pretty straightforward.

Now the moment you’ve been waiting for – the code for the 3 pages we’ve used itself. Note that I’ve also used a custom Master page for my sites – you’ll want to build your own, with your own navigation, etc..

Our ListView shows our users. Each user has a checkbox next to them:

I’ve added a ‘Remove Users’ LinkButton to my fake ‘toolbar’:

That LinkButton is defined in my page as:

<asp:LinkButton UseSubmitBehavior="false" id="BtnRemoveUsersFromGroup" runat="server"
Text="Remove Users"
OnClick="BtnRemoveUsersFromGroup_Click"
OnClientClick="return BtnRemoveUsersClick();"
/>
So, on click it runs some client script, and then posts back a click event. So, how do you know which users have been selected within the postback? You could have zero-to-N checkboxes!

Well, the client script is some JavaScript that checks all the checkboxes, appends their values into a hidden field, and it’s that hidden field that is posted back for the click event.

This function gets the selected users (yes, I’m using a bit of jQuery – it was much neater):

function GetSelectedUsers(attributeName, separator)
{
var result = "";
var users = $("input:checkbox[name^='spUserSelectionCheckBox']");
for (var i = 0; i < users.length; i++)
{
var chkBox = users[i];
if (chkBox.checked)
{
var attributeValue = chkBox.getAttribute(attributeName);
if (attributeValue != null && attributeValue.length > 0)
{
if (result.length > 0)
{
result = result + separator;
}
result += attributeValue;
}
}
}
return result;
}
And this function puts all the selected users into our hidden field:

function BtnRemoveUsersClick()
{
var userIds = GetSelectedUsers("value", ",");
var userNames = GetSelectedUsers("account", ",");
var confirmMessage = "<SharePoint:EncodedLiteral runat='server' text='<%$Resources:wss,people_confirmremoveusersfromgroup%>' EncodeMethod='EcmaScriptStringLiteralEncode'/>";
var noUserSelectedMsg = "<SharePoint:EncodedLiteral runat='server' text='<%$Resources:wss,people_nouserselected%>' EncodeMethod='EcmaScriptStringLiteralEncode'/>";
if (userIds.length == 0)
{
alert(noUserSelectedMsg);
return false;
}
var hdn = (document.getElementById("<%= HdnUsersToRemove.ClientID %>"));
hdn.value = userIds;
var msg = StBuildParam(confirmMessage, userNames);
if(confirm(msg))
{
<%= Page.GetPostBackEventReference(BtnRemoveUsersFromGroup) %>;
return true;
}
return false;
}

For completeness, our hidden field is an ASP.NET control…

<input runat="server" type="hidden" id="HdnUsersToRemove" />

Yuck! So, in JavaScript, we get all the checkboxes, identify the selected users, put them into a hidden field, and then postback our button’s click event. Thus, in my code behind, I have to split up my string of IDs of selected users, and remove the users:

web.AllowUnsafeUpdates = true;
string[] usersToRemove = HdnUsersToRemove.Value.Split(new char[] { ',' });
foreach (string user in usersToRemove)
{
group.Users.RemoveByID(int.Parse(user));
}
group.Update();
web.AllowUnsafeUpdates = false;

And that’s the last main bit of it.

Well, on our ‘list of users’ page, I have what looks like a a SharePoint toolbar. It’s actually just a table cunningly formatted to look like a toolbar, and the ‘Add users’ link on it is a LinkButton. In the codebehind it’s click event is:

protected void BtnAddUsersToGroup_Click(object sender, EventArgs e)
{
int iGroup = (int)ViewState[GROUP];
SPUtility.Redirect("SimpleUG/AddUsers.aspx?MembershipGroupId=" + iGroup, SPRedirectFlags.RelativeToLayoutsPage, this.Context);
}

So, all we’re doing is going to a page called ‘AddUsers’ and passing the MembershipGroupId again.

This page looks like:

It’s much simpler than the normal add users page. We’re not giving the administrators as many options, which I think they’ll thank us for.

All we’ve got here is a PeoplePicker control. In the main content area of our page (having stripped out a lot of formatting) we’ve got:

     <wssawc:PeopleEditor
AllowEmpty=false
ValidatorEnabled="true"
id="userPicker"
runat="server"
ShowCreateButtonInActiveDirectoryAccountCreationMode=true
SelectionSet="User,SecGroup,SPGroup"
/>
<asp:Button UseSubmitBehavior="false" runat="server" OnClick="BtnOK_Click" Text="<%$Resources:wss,multipages_okbutton_text%>" id="btnOK" accesskey="<%$Resources:wss,okbutton_accesskey%>"/>

So, a lot of formatting, a PeopleEditor control, and a button to click OK. The main bit of the click event handler for the button is:

SPSecurity.RunWithElevatedPrivileges(delegate()
{
using (SPSite site = new SPSite(webUrl))
{
using (SPWeb web2 = site.OpenWeb())
{
web2.AllowUnsafeUpdates = true;
for (int i = 0; i < pickedList.Count; i++)
{
PickerEntity current = (PickerEntity)pickedList[i];
SPUser user = web2.EnsureUser(current.Key);
group.AddUser(user);
}
web2.AllowUnsafeUpdates = false;
}
}
});

Here, for the group we’re adding to, we get each picked SPUser for the PeoplePicker, and add them to the group. Then I return the user to the list of users page.

If you knew the ID in advance, you could hard code it. I didn’t, so I used a redirect page. My page accepts a GET parameter of ‘OWNERS’, ’VISITORS’, or ‘MEMBERS’ and redirects to the ‘list users’ page with the correct group ID. Again, I wrote this page in visual studio as  code behind page to go in the _layouts directory.

protected void Page_Load(object sender, EventArgs e)
{
string group = Request.QueryString["group"];
SPWeb web = SPContext.Current.Web;
int igroup = web.AssociatedMemberGroup.ID;
if (group != null)
{
if (group.ToUpper() == "OWNERS")
{
igroup = web.AssociatedOwnerGroup.ID;
}
else if (group.ToUpper() == "VISITORS")
{
igroup = web.AssociatedVisitorGroup.ID;
}
}
SPUtility.Redirect("SimpleUG/ListUsers.aspx?MembershipGroupId=" + igroup, SPRedirectFlags.RelativeToLayoutsPage, this.Context);
}
That’s all there is too it – it get’s the ‘associated’ group for the web. You could do whatever you want here, though – look up specific groups by name, permission level, as specified elsewhere, whatever. I then built into the navigation of my site links to things like:

/_layouts/SimpleUG/UserAdmin.aspx?Group=OWNERS

which would resolve the ID of the Owners group, and forward the user to a list of the users in that group.

<SharePoint:ListView id="UserListView" ListID="UserInfo" runat="server"/>

And my page showed:

This is a SharePoint ListView, and the id and ListID appear to be ‘magic’ values. If set as above, the web part will display the users in the group specified by the MembershipGroupId GET parameter for the page. Try it – go to the normal users and groups pages, to to view the members of a group, and try replacing the integer ID of the group. (Not all are used)

So, that bit of magic shows me the list of users. In my page’s OnLoad event I also read the MembershipGroupId parameter and used that to read the name of the group we’re editting, which I then used in the PageTitle area. We’ll see this later.

(My Site is called ‘Blank’ and we’re editing the ‘Blank Members’ group)

That’s all I needed really, but as a bonus I’m also going to describe how I added the View Control.

The toolbar above my web part is actually an HTML table that I built by hand. The Add Users and Remove Users buttons are link buttons that I’ll describe in a later post. For now, let’s concentrate on the ‘View Selector’ on the right.

To add this, I dug through the ordinary People and Groups pages and dug out the following code:

<TD noWrap >
<SharePoint:MenuTemplate runat="server" id="MenuTemplateView"/>
<table border=0 cellpadding=0 cellspacing=0 style='margin-right: 4px'>
<tr>
<td nowrap id="topPagingCell">
<td>
<td nowrap>&nbsp;</td>
<td nowrap><SharePoint:EncodedLiteral runat="server" text="<%$Resources:wss,view_selector_view%>" EncodeMethod='HtmlEncode'/>&nbsp;</td>
<td nowrap onmouseover="this.className='ms-viewselectorhover'" onmouseout="this.className='ms-viewselector'" id="onetPeopleViewSelector">
<SharePoint:Menu id="MenuViewSelector" runat="server"
TemplateId = "MenuTemplateView"
Text="<%$Resources:wss,multipages_new_menu_text%>"
MenuFormat="ArrowAlwaysVisible"
MenuAlignment="Right"
AlignmentElementOverrideClientId="onetPeopleViewSelector"
HoverCellActiveCssClass = "ms-viewselectorhover"
HoverCellInActiveCssClass = "ms-viewselector"
ArrowImageUrl = "/_layouts/images/blank.gif"
AccessKey = "<%$Resources:wss,tb_ViewSelector_AK%>" />
</td>
</tr>
</table>
</TD>
A lot of this code is actually HTML for the tables for format the control. The main two controls are the SharePoint Menu control and MenuTemplate controls. How they work here, I don’t know (a lot of this page was figured out using Reflector) – but it does give you a dropdown with the different views (Details and List) of the group in it.

If I was using different views, I needed to set my ListView to use the correct one. I did this in the Page’s OnLoad event, so my code became

protected override void OnLoad(EventArgs e)
{
base.OnLoad(e);
UserListView.ViewId = this.CurrentViewId.ToString("B");
this.UpdateViewSelector();
string groupId = Request.QueryString["MembershipGroupId"];
int iGroup = 0;
if ((groupId != null) && (int.TryParse(groupId, out iGroup)))
{
ViewState[GROUP] = iGroup;
SPWeb web = SPContext.Current.Web;
foreach (SPGroup group in web.AssociatedGroups)
{
if (group.ID == iGroup)
{
PageTitle.Text = group.Name;
PageDisplayTitle.Text = group.Name;
break;
}
}
}
else
{
ViewState[GROUP] = null;
}
}

Here you can see I set the ListView’s current view, based on the GUID for that view, and then get the group’s name for the page’s title. Now, in there there is a call to UpdateViewSelector – this reads as:

private void UpdateViewSelector()
{
this.MenuTemplateView.Controls.Clear();
MenuItemTemplate template;
foreach (SPView current in UserListView.List.Views)
{
if (!current.Hidden)
{
template = new MenuItemTemplate();
template.Text = current.Title;
template.ClientOnClickScript = "NavigateToView('"
+ SPHttpUtility.EcmaScriptStringLiteralEncode(current.ID.ToString("B").ToUpperInvariant()) + "')";
this.MenuTemplateView.Controls.Add(template);
}
}
LiteralCurrentViewId.Text = CurrentViewId.ToString("B").ToUpperInvariant();
SPView view2 = UserListView.List.Views[this.CurrentViewId];
this.MenuViewSelector.Text = view2.Title;
}
This is setting up the View Selector’s MenuTemplate. It clears any existing menu items, and then adds one for each view in the ListView.

The final bit of code related to the View Selector is the page’s CurrentViewId property. This property returns the id of the view that’s currently being used, and it reads as:

   private Guid _currentViewId = Guid.Empty;
protected Guid CurrentViewId
{
get {
if (_currentViewId == Guid.Empty)
{
string g = base.Request.QueryString["View"];
Guid empty = Guid.Empty;
if (g != null)
{
empty = new Guid(g);
}
SPView view = null;
foreach(SPView current in UserListView.List.Views ) {
if (!current.Hidden && (((empty == Guid.Empty) && current.DefaultView) || (empty == current.ID)))
{
view = current ;
}
}
if (((view == null) && (empty == Guid.Empty)) && (UserListView.List.Views.Count > 0))
{
view = UserListView.List.Views[0];
}
if (view == null)
{
throw new SPException(SPResource.GetString("ViewGone", new object[0]));
}
_currentViewId = view.ID;
}
return _currentViewId;
}
}

This returns the GUID of the view being currently used.

The worst part is, though, often users just want to add or remove users from a pretty limited set of groups. I mean, this is implied by the standard ‘Visitors/Members/Owners’ groups on a site. Unfortunately, there are often a lot of other groups, and other complexities shown through the standard user interface in SharePoint.

For a Case Management system we’ve been working on, I built a simplified user interface. The idea was to make it easy for non-techies to add and remove users from specific groups. They weren’t to have access to all groups, and this wasn’t to replace the ordinary People and Groups pages – so more technical staff could still use those too. What I came up with is shown below.

It appears similar, initially – but the navigation on the left is the same as for the rest of our case site. Only the relevant groups (“Case Workers” and “Case Owners”) are linked to on the left, and these links are only shown to users who can edit the groups (Home and Audit aren’t related to people and groups). Also, the menus on this page only let users add or remove users – which is all they should need to do.

Note that the “Case Workers” and “Case Owners” groups are just the groups we happened to be using – you could build this to work for others, depending on your needs.

I built this user interface using 3 application pages put into the _layouts directory. They’re actually Code Behind ASPX pages, and so this is a Visual Studio solution, though some sections of the application could be built in SharePoint Designer.

The pages themselves are for:

• Listing the users and letting admins remove users.
• A page for adding new users.
• A redirect page for identifying the correct ID for the group we want to edit.

The solution is a little complicated, so I’m going to break it down into pieces:

• Introduction
• How to Display a list of users
• How to Find the MembershipGroupId
• How to Add Users
• How to Remove Users
• Conclusion

properties.AfterProperties["Tax Area"] = "Europe";

In our case, however, we didn’t know what these properties were before hand. Rather, we were ‘inheriting’ values from a parent folder. Thus, we were going to use the parent folder’s SPField object for each field to define the value. I started out using:

properties.AfterProperties[parentField.Title] = parentItem[parentField.id];

But is Title the right property to use? Well, having looked through a number of blog posts, this seems to be the subject of some confusion.

At first Title is okay to use. However, you can change the display name of the field. For example, we could change our field’s Title to ‘Tax Region’ – but we still need to use ‘Tax Area’ in our AfterProperties collection.

So, InternalName is the right property of the SPField to use – but there is a hiccup. The InternalName is encoded – Tax_x0020_Area – so you have to unescape it like I’ve talked about before.

The summary is, then, use the unescaped InternalName in your AfterProperties collection.

Hello World

Gets encoded to:

Hello_x0020_World

So what’s the _x0020_ number about? Well, hex 20 is the UTF value for a space, and x0020 represents that space. I guess the underscores are delimiters. The reason for this escaping is that XML element names can’t have a space.

How would I encode or decode this? Well, the clue is in the phrase ‘XML element names’. You can use:

• System.XML.XmlConvert.EncodeName() to encode
• System.XML.XmlConvert.DecodeName() to decode

Both are static.

?contents=1

Takes you to the Web Part Maintenance Page. I can never remember the bit you add to the URL

The problem is, they want this value to be pre-populated before the EditForm.aspx page is displayed.

Here, for example, the Case ID is autopopulated from the parent folder. So, what’s the best way of doing that?

Well, clearly an SPItemEventReceiver class seems a good bet. We can override one of the events, and in the event get the parent folder, and map across any column values. But what event should we override?

• ItemAdding seems a good choice. This is a ”Synchronous Before event that occurs when a new item is added to its containing object“. However, because this is before the item is added, there is no SPListItem object to write the values too, or to even see what fields the item has.
• Consequently, my colleague had decided to use the ItemAdded event. This is an “Asynchronous After event that occurs after a new item has been added to its containing object.” Note that is is Asynchronous. That is, it runs in a different thread, at an indeterminate time.

As has been blogged about elsewhere, this puts the EditForm.aspx page and our event handler into race conditions. The edit form contains a ‘last update’ time, to detect concurrent updates. Our event handler update the item. The possible outcomes are:

• If the event receiver wins, all is good. The item gets it’s parents values, then the edit form displays with those values.
• If the form wins, it displays without any inherited values. Then the event receiver updates the item, which means that when the users tries to save changes they’ve made in the edit form, they receive an error telling them “The file X has been modifed by Y“

So, what’s the solution? Well, although the ItemAdding event doesn’t have an SPListItem to set the values for – ‘cos it’s not been created yet - the properties of the event does have an AfterProperties collection. This is a set of values we want set in the properties of our new item when it is finally created. Note that the collection is keyed on the DisplayName, not the InternalName, at least on my system.

Now, we don’t what the Fields we’re mapping are beforehand. And as our SPListItem doesn’t exist yet, we can’t look the up – so how do we handle that? Well, I copy all the parent Folder’s properties. Fields that are the same on the child will use the value of the appropriate property – and additional properties won’t be used. For example, if our Folder has a ‘Case Owner’ and our Document does not, we’ll be setting a property called ‘Case Owner’ on the child item – but it isn’t used, and so it isn’t a problem, and we can always find and remove it on ItemUpdated.

public override void ItemAdding(SPItemEventProperties properties) {
//Get the URL to the folder we're working at.
using(SPWeb web = properties.OpenWeb()){
string url = properties.BeforeUrl.ToString();
url = url.Substring(0,url.LastIndexOf("/"));
//Get the folder we're using. Get the ListItem too (if it has one
// - root folders don't
SPFolder folder = web.GetFolder(url);
SPListItem folderItem = folder.Item;
//If not a root folder...
if (folderItem != null) {
//For each folder field, if it's inheritable, add it as a property.
//This may add unnecessary properties - ones for which the child doesn't
//have a field. See ItemUpdated.
SPContentType folderContentType = folderItem.ContentType;
foreach (SPField field in folderContentType.Fields) {
if (IsInheritable(field)) {
properties.AfterProperties[field.Title] = folderItem[field.Id].ToString();
}
}
}
} //End Using
}

EDIT – there is an error in this code – AfterProperties should be set as shown here, not using field.Title

Note that the IsInheritable function is ‘cos we do have some extra criteria over what fields to map (they have to be from a certain Group of Site Columns)

Both these web parts look kind of similar. They should do – they use the same control to display the charts – the ASP Chart control in System.Web.UI.DataVisualization.Charting library.

MSDN doesn’t seem to have much info on this; it implies that it’s part of the .NET 4 beta, but it is definitely available in 3.5 – Scott Gu says so, and observation shows he’s right!

We had a problem, though, on one of our system that sometimes the chart image would be displayed correctly – but most of the time you just got an ‘error’ box where the image should be. If you kept refreshing the page, occasionally it would show the image, but mostly it showed the error box – but it seemed pretty random as to when it would work or not.

It struck me that I should understand the configuration I’d put into the Web.Config. While doing this, I noticed that the value for the ‘ChartImageHander’ setting was

<add key="ChartImageHandler" value="Storage=memory;Timeout=20;" />

I wondered what the storage options were. I mean, if there were multiple servers you’d be relying upon Sticky Sessions to get the right server that has your image stored. Well, I found this blog post (and later, this documentation) that describes it. I noticed:

memory: Store the rendered chart images in the memory space of the running process. Do not use this option in a server cluster or a multiple-process site.

That’s enough to make me suspicious. Instead, I created a directory to hold the chart files, and used

<add key="ChartImageHandler" value="Storage=file;Timeout=20;Dir=c:\charttemp\" />

One additional note – I’m not sure if the ChartImageHandler should also include ‘DeleteAfterServicing=false’ to act like a cache. Sure, the chart wouldn’t get updated right away each time – but neither would it have to be rendered so often. I might look into that at some point…

Others have written good descriptions of what CAS Policy is (here is a good description by Bamboo), but the short description is that it tells your application (SharePoint) to give certain additional rights to an assembly (in our case, the web part). These rights are things like being able to access the disc, the network, or even the SharePoint Object Model!

Yup, that’s right – under default Code Access Security, my assembly wouldn’t even be able to access the SharePoint APIs.

Anyway, I started looking into I’d have to do to add a policy. Basically, it’s a lump of XML that goes in the Manifest file of your WSP. Conveniently, I discovered, WSPBuilder automatically performs reflection on my assembly, and generates a CAS Policy by itself:

If you open that image up, what you’ll see is a set of permissions being defined, and then at the bottom the assemblies (just the one in my case) that those assemblies apply to.

I was surprised that my automatic CAS policy contained rights for things like File IO, SMTP and SQL Client – but my web part uses the SharePoint object model, and that probably uses all those rights.

So, an automatically generated CAS Policy – nice, neat! It didn’t work. I kept getting an error that my web part didn’t have the Microsoft.SharePoint.Security.SharePointPermission.

Well, for some reason the reflection that generated the CAS Policy came back with the wrong description for that permission. It used just ‘SharePointPermission’, but the CAS Policy needs the full strong name.

On looking at WSPBuilder I found that I could specify my own file containing additional permissions:

WSPBuilder.exe -WSPName CreateNewDocumentWebPart.wsp -CustomCAS CasPolicy.txt

That file contained a declaration of a classes that implement the IPermission interface. This include the SharePointPermission using the full strong name:

(There are others here; I was experimenting)

WSPBuilder then created the Manifest file with my permissions:

And that worked; all my permissions exceptions went away. My web part worked without elevating trust for my entire farm, or putting my assembly in the GAC (which gives the whole assembly Full Trust).

Kudos to @Einaros for pointing me toward the right declaration for the Microsoft.SharePoint.Security.SharePointPermission

How are you applying styles to your custom web parts in #SharePoint? using CSSClass property, stuck on deploying css <Link> tag in the head

Well, for pages themselves you have the CSSRegistration control. It’s an ASP.NET control, and looks something like:

<SharePoint:CssRegistration name="/_layouts/myBrand/SomeStyle.css" runat="server"/>

This control registers the URL with the page, but doesn’t emit anything. That’s controlled by the CssLink control:

<Sharepoint:CssLink runat="server" />

It actually outputs the <link> elements, and this means that you can have a CSSRegistration control low down in the page (in a Content control, for example) and you can still output it in the <head> of your page. There’s a good post about this on CleverWorkarounds. 

So, could we use that control? Well, we should be able to instantiate one – except it turns out that we don’t have to. We can just use the CSSRegistration.Register() static method – something like:

protected override void CreateChildControls(){
CssRegistration.Register("/_layouts/myBrand/SomeStyle.css");
}

Job done…

I’m not sure I can describe the system I’m actually working on, so I’m going to use a slightly contrived example…

We’ve got data in a SQL server database, and we want to expose this via the BDC. In particular, we want to expose the data to SharePoint search.

In my contrived example we’ve got a couple of entities – Person and JobTitle. A Person entity has a JobTitle. In the database it might look something like:

Person:

Job Title:

Clearly, JobTitleID is the foreign key to the JobTitle table. We’re also using a Last Updated date/time to allow use to incrementally index the database with the BDC.

Now, you’ll note that we’ve got 2 people called John Smith. I do mean that we’ve got two people, not that John Smith has two jobs. What I’d like to be able to do, then, is search for “John Smith Painter” and get one record, or “John Smith Plumber” and get the other. In short, the Person entity is the important one; Job Title is just a look-up.

Unfortunately, while we can index these tables via the BDC, essentially the relationship is lost. A Search for “John Smith Painter” would return 2 matches for the “John Smith” part (our two people) and 1 match for the “Painter” part (our job title).

Ideally we could denormalised this database structure, and store the person’s job against their record directly. Sadly, for the system we’re working with this isn’t really an option.

So, what I can’t figure out is how to get the BDC to index our Person entity and related entity data as a reference to our Person record. I don’t know if anyone has any ideas, but I’d come up with:

• Denormalise the data (we can’t really do for certain relationships)
• Build a separate ASP.NET web site to display our data and index that (but would screw up incremental index)
• Write a custom protocol handler (complex, scary, and probably expensive) (Although this codeplex project might help)

If anyone has other suggestions or tips, let me know!

Sometimes, though, you want to programmatically create and enable these lists. That’s cool – but how do you figure out the email address of the list afterward?

You can get the first part of the address from the SPList object’s EmailAlias property. But that’s only the bit before the ‘@’ sign – what about the end of the address? Well, you get that from the farm:

emailAlias = list.EmailAlias + "@" + SPFarm.Local.Services.GetValue<SPIncomingEmailService>("").ServerDisplayAddress;

This gets the rest of the address (in my case ’sharepoint.virtual.local’). Job done.

Anyone got recommendations to how you modify RSS-Settings for an SPList object using the API?

Good question. The SPList object does have a property EnableSyndication that gets or sets whether an RSS feed is available. There is also an property ‘AllowRssFeeds’, but it is, apparently, read only.

So, you can set whether one is allowed or not – but there are a lot more settings. What about controlling them programmatically?

I mean, the settings page in SharePoint looks like this:

Where are those settings? Well, looking in SharePoint Manager (fantastic tool) we can see:

These settings are actually properties on the Root Folder of the SPList (i.e. SPList.RootFolder.Properties). To check this I wrote some code to look through the properties and output them to the console:

And this output:

So, what are the RSS specific properties (there are plenty of other properties in the RootFolder – email enabled list settings, for example):

• vti_rss_ChannelTitle (string) – The Name of the Rss feed
• vti_rss_ChannelImageUrl (url as a string) – the url of the image to use in the RSS feed
• vti_rss_ChannelDescription (string) – The description of the RSS feed.
• vti_rss_ItemLimit (int) – the maximum number of items in the feed
• vti_rss_DayLimit (int) – the maximum number of days to include items for.
• vti_rss_DocumentAsLink (bool as 0 or 1) – Link Rss Items directly to their files? If 1, the title of the Rss Item links directly to the file
• vti_rss_DocumentAsEnclosure (bool as 0 or 1) – Include file enclosures for items in the feed? If 1, the Rss Item contains a link to the file.
• vti_rss_DisplayRssIcon (bool as 0 or 1) – Unknown. Doesn’t seem to do anything
• vti_rss_DisplayOnQuickLaunch (bool as 0 or 1) – Unknown. Doesn’t seem to do anything.
• vti_rss_LimitDescriptionLength (bool as 0 or 1) – Truncate multi-line text fields to 256 characters?

So, you can set those values and change your RSS settings. Should all be pretty obvious now. Don’t forget to do RootFolder.Update() when you’ve changed the properties…

EDIT: Tobias blogged about this himself too.

However, as far as I know nobody has yet figured out a way of putting rounded corners on the bottom corners of web parts. The HTML they have does not suit them to do this via CSS. The only idea I’ve had previously was to use ControlAdapters to modify the output of of the Web Part itself. And I’m pretty sure you’d have to write an adapter per web parts. That kind of sucks; no customer is going to be in a hurry to pay for that.

Well, when I was looking at putting borders around an entire web part zone, I had a thought. What we really need to do is insert elements into our page. jQuery can do that sort of thing. Could I use jQuery to find each web part and wrap some tags around it?

Looking in the HTML produced for a page, I noticed that web parts all seem to exist in a table cell with an ID that begins ‘MSOZoneCell_WebPart‘ so I tried querying for that, and wrapping it in DIV tags (the same structure as used yesterday for the whole zone):

Erm, this worked (Image below is just one web part zone):

Clearly, that style sucks. And you’d want to work on the styles of the web parts themselves – removing borders and the like. And I think that having separately styled ‘titles’ and ‘bodies’ might be… awkward. But those are borders around individual web parts. They do show up in Edit mode, and they do move when you drag the web parts around:

Unfortunately, I do seem to be getting a JavaScript Error now. When I open it up to look at it I see:

I’m pretty sure I’ve never written 120 million lines of code, so I’m not quite sure what’s going on here. It doesn’t seem to cause any problems though. I don’t know if somone can take this prototype on and solve that one – but I can’t find the problem. It sounds very similar to this bug report.

Anyway, one design requirement that come up repeatedly is rounded borders on Web Parts. I swear, it comes up with every design – and it isn’t possible (although I have an idea – more on that tomorrow). What you can do, though, is have a rounded border about the entire web part zone…

Of course, the problem with this is that if you put two web parts in one zone you get something like the following:

Actually, that can sometimes work quite well, but it’s something else to consider when you (or your users) are laying out their web parts. Still, it’s pretty easy – here are the image files used for the border (I put them into a folder in LAYOUTS):

I then put a whole bunch of DIV tags into my page for the borders. I don’t like having all of them, but it’s a fairly standard way of doing this (browsers – please support CSS for corner radius soon).

Yuck! Lots of DIVs, but combined with these CSS Styles …

… it puts our border around our web part zone. Obviously, for a real system you’d use a nice looking border – mine is for prototype only.

One issue that remains, though, is what happens if there are no web parts in the web part zone? Well, as it stands you’d have a nice empty box which would shrink to its minimum size, as there are not contents. This isn’t ideal – if it’s empty, we’d rather not see it at all. SharePoint seems to deal with this for square borders using the MSO_Layouts_MakeInvisibleIfEmpty() Javascript function. JavaScript? Pah! Quaint and old school – I used a bit of jQuery:

What this code does is get the innermost DIV tag of every bordered area. If that DIV tag doesn’t have any children, we find the first parent DIV tag at the ‘top’ of my set of nested DIVs, and hide it! And that works nicely:

Next up, I’ll take a look at borders on web parts themselves…

Anyway, I was interested that the themes could all be activated as features. This rather kept with my feeling on how branding should be deployed.

However, some of the themes (though not all) were suddenly available in the ‘Site Themes’ page of my SharePoint system. I knew from experience that this isn’t something that ‘just happens’ – previously, I’ve done it by hand.

EDIT: See the comments – they describe an possible pit fall, but both have articles about how to do the same thing…

I became curious, so I opened up Reflector. I found that there is a method called when the feature is installed to update the SPThemes.xml file:

ModificationType is just a private enumeration to tell you whether you are adding or removing an entry from the SPThemes file. This code is called from within a Feature Receiver during  FeatureActivated FeatureInstalling (need to check, see comments below)

Anyway, I’ll remember this in case I should need to do similar. Obviously, the original code is probably simpler than the decompiled stuff.