My colleague wanted to create a new list item but certain fields were coming through as mandatory.

I checked this in Sharepoint Designer Workflow and encountered the same issue.

We checked over the list and all the columns in the content types appeared to be fine.

After much looking I noticed that there are 2 sets of fields on the List Template.  The first are those which were created before the manage content type was activated, the 2nd were attached to each of the content types.

We turned off manage content types and noticed that 2 columns in the list were marked as required, setting these to optional and then reactivating manage content type resolved the issue.

I started off by creating the Time Sheet library with the appropriate columns, for each Yes/No column I created a mirror calculated column for storing a numerical value.  The calculation basically said if checked then 1 else 0(actual statement is =IF(myField=TRUE,1,0).

To create a weekly total I created a workflow in designer that was fired on the update event.
 

This is where my major problems started, the first thing I noticed was that the work flow took ages to complete if it ever did, and when I clicked the item I either received a “Server Out of Memory” message or a “Some part of your SQL statement is nested too deeply” error message.

I traced all of my problems back to the Set Total to Variable:Total statement.  Apparently, if within your workflow you update a field on the current item and you have the run workflow when item is updated ticked, the code will disappear into a never ending loop.

The only way I have found to stop this is to use a semaphore type approach.  Basically I have a column on the form called update record.  By default the column is set to No.  If the user wishes to submit their record they have to tick the Submit Record box.  Within the workflow I have coded a condition which says if Submit Record equals Yes then do the calculation, within this branch I then set the Submit Record back to No and then update the Total. 

This does not stop the workflow from firing it will fire twice per update, but the 2nd time will do nothing as the condition will be false.

I will be looking at ways to do this via script on the edit form and will keep you posted.

Anyone who’s done this will know there is a very good provider who are offering a free solution.
The issue we have had is that after implementing the solution we were no longer receiving search usage data.

Having spent several days looking for the cause I discovered that if you deploy the Out of the Box Sharepoint Search Text Box web part to the results page, you got the data, if you used the results one you didn’t.
The upshot of this was that, as the provider had used a custom Search box, the Sharepoint data in our instance never got recorded unless we deployed the standard search box  to the results page.

Having done some further research I discovered that all MOSS Search web parts utilise a Sealed object Microsoft.Office.Server.Search.WebControls.SearchResultHiddenObject

This object is  responsible for handling best bets, relevance, results and running the query itself.  It is within here I believe the usage data is updated.  Despite crawling through the API libraries I can find no methods to update the Search Usage.  It would also appear that the information isn’t picked up from the log files so again I assume the updating is all handled via this object.

If this is the case it will not be possible to run bespoke queries and get the usage data to report on the terms/results.

Anyone agree/disagree with this, I have posted all over the place but not received any response

Here are some links to other information round searching.

http://msdn2.microsoft.com/en-us/library/bb608304.aspx

http://www.sharepointforum.com/en-US/Wiki/The%20good%20news%20and%20the%20bad%20news%20on%20MOSS%202007%20search.aspx

Well in MOSS 2007 there is a way to do it.

We will need the following namespaces:
Microsoft.Office.Server
Microsoft.Office.Server.UserProfiles

So the first job is to get a context and the UserProfileManager object.  You can get the context using amongst others the SPSite or SPWebApplication object.

In this example we use a pre-created SPSite object.

ServerContext sContext = ServerContext.GetContext(site);
UserProfileManager pm = new UserProfileManager(sContext);

From here you can use the pm.MySiteHostUrl Property.  This will get you the protocol, the hostname and any ports.  From here you build any specific pages or URL parameters.

Alternatively you can use the pm.GetUserProfile(~LoginName~) to get the UserProfile object and from there use the PublicUrl.AbsoluteUri to return the full URL to the person.aspx page with the applicable accountname parameter set.

Full Code Listing
using (SPSite site = new SPSite(“http://…”)){
  ServerContext sContext = ServerContext.GetContext(site);
  UserProfileManager pm = new UserProfileManager(sContext);
  string url=pm.MySiteHostUrl;
  UserProfile up=pm.GetUserProfile(“AD\\MyGSN”);
  string personnelURL=up.PublicUrl.AbsoluteUri;
}

What can I say, I’ll be sorry to see Plumtree go but it’s time to embrace the brave new world.

So what did we achieve?

• We built a custom tool that Migrate Projects from Plumtree to Sharepoint, mirroring security and audit history
• We built a custom web part that can query folders/views cross site collection and build a treeview from what it finds.  This is our primary navigation, our site map and used as an Explorer style tool for looking at document libraries in other site collections
• We implemented a User Interface that was so close to our bespoke Plumtree one, no users could tell the difference at first sight
• We migrated 170 communities and over 400 projects in around 2 months using a migration team of 6 and 5 unbelievably adaptable business representatives

Click here to read all about it

To regain control of your page browse to

http://YourURL/_layouts/spcontnt.aspx?&url=%2fSubSite%2fSubFolder%2fPageName

or in my case

http://spintranet/_layouts/spcontnt.aspx?&url=%2fRich1%2fpages%2fdefault.aspx

This will take you to the maintenance screen that will allow you to Reset/Remove web parts for the specified URL

One of the requirements when moving from Plumtree to Sharepoint was the ability to store data which wasn’t contained within the users AD profile in the Portal.

In Plumtree this was quite straightforward and in Sharepoint it’s supposed to be quite easy too.

Simply go to the SSP and select User Profile and Properties link

Towards the bottom is the Add Profile Property link.
Selecting this will allow you to configure the property, it’s internal and display name, content type etc.

The important part for me was the replicable setting.
This allows you to push the value from this property down to all Site Collections.

The display setting is also important as this controls which sections this property appears in.

Towards the bottom you can specify an existing Data Store to get the property data from

The various other settings should be self explanatory.

You will need to have the content db marked as Ready and wait for the Profile Synchronization job to run before the properties appear

Editing

When editing properties there are 3 main sections.

• Within the SSP
• Within the Site Collection
• On the users My Sites

The SSP is obviously a no no as users will not have access to this.
The Site Collection doesn’t allow you to update fields even though this is where the My Settings and the Edit Item links take you.
The only other place is My Sites.  It is possible to edit a user profile without having an actual My Site created.  It’s little known that within the UserDisp.aspx page, there is a redirect control.  If you have specified a My Site location in the Portal Connection field.  Then all traffic will be routed away from the UserDisp.aspx to the users Profile Page on their My Site.

This is great, except that

• You might want to be connected to another Portal
• You may have many Site Collections and this will be a pain
• You don’t want the My Site Portal name appearing in the site navigation

To work around this you will need to use a feature which will apply a delegate control

This is as simple as creating a feature with an Elements file and use the control element with an ID of ProfileRedirection(used in the UserDisp page) and specifying an ascx page location.  You may also specify a sequence to ensure yours appears above any others

The ASCX page will be called each time the page is loaded.  This means you are not modifying Sharepoint central files.  Particularly important when sharing hardware or paranoid about patching.

In our ASCX we simply check the URL, if it starts with a certain address we redirect, otherwise we don’t

To obtain the URL of the My Site, check out my article over here

This article is useful, and has some good links http://blah.winsmarts.com/2007-7-SharePoint_2007__All_you_ever_wanted_to_know_about_User_Profiles.aspx

No problem I think we have the source feed and it provides the information with the last updated date in GMT.  Unfortunately they want the FTSE price in GMT and the NYSE in EST.  Converting times accurately between time zones on a server with a differing time zone to the required 1 has been a notorious headache especially when you factor in daylight saving time.

This has been made easier with .NET 3X TimeZoneInformation class but I am not coding in .NET 3.x for Sharepoint were using 2.0, but I did find a Sharepoint equivalent.

The final solution was to store the time in UTC and then use the SPRegionalSettings.GlobalTimeZoneSettings[].UTCToLocalTime to convert the time to the appropriate time.

So for a date object like 26-FEB-08 16:56 GMT

Simply myDT=DateTime.Parse(“26-FEB-08 16:56 GMT”);
myUniversalDT=myDT.ToUniversalTime();
string estTime=SPRegionalSettings.GlobalTimeZones[14].UTCToLocalTime(myUniversalDT).ToString();

string gmtTime=SPRegionalSettings.GlobalTimeZones[28].UTCToLocalTime(myUniversalDT).ToString();

So there you go, this uses out of the box Sharepoint 3.0 functionality to convert UTC times to EST(14) and GMT(28) obviously this could be expanded to for loop through the objects and then you wouldn’t need to hard code the indexes.

The first job is to get hold of the web application

SPWebApplication spWA= SPWebApplication.Lookup(new Uri(http://mySite));

Next you can use the Sites collection to create the appropriate Site Collection
The new site collections URL can either be in the format mySiteCollection or managedpath/mySiteCollection

int32 lcid=1033;
string template="STS#2" //Get the one you want here
SPSite spS=spWA.Sites.Add(url,"SiteName","SiteDescription",lcid,template,"\\domain\ownerloginname","Owner Name", myemail@here.com)
There are a number of Add methods allowing you to configure owners, secondary owners, and config databases.  Full list here

Once you have done this you will need to add the groups.
This is quite straight forward using the new site collections rootweb property and inturn the SiteGrpups collection

SPWeb spW=spS.rootWeb;

The trick now is to add the group.  The issue here is that you will need an SPMember object which is either SPGroup or SPUser for the owner object.
The problem I encountered is that unless the user is part of the Root Web then they can’t be added as a Group owner.  The group will half create and the API will not throw an Exception.  What you will end up with is a Link in the Site Groups area of teh Site Collection, that errors when clicked. Also the SiteGroups count property will not reflect the new group, but you will not be able to add a group with the same name without receiving a name already exists exception

There are several ways to get a user object.  One involves a straight spW.SiteUsers.Add(…… lots of data)

the other uses the Microsoft.Office.Workflow.Utility and generates a Contact, then uses this to get the actual user object. 

Contact contact=Contact.FromName(userloginname,spW);
if(contact.PrincipalID < 0){
     //this actually adds the user to the site collection users list
     SPPrincipal p=contact.GetPrincipal(spW);
}
SPUser owner=spW.SiteUsers[contact.LoginName];
spW.SiteGroups.Add(spW.Title + " Owners",owner,null,"This is the default owners group")
SPGroup grpOwner=spW.SiteGroups[spW.Title + " Owners"];
spW.AssociatedOwnerGroup=grpOwner
//Repeat for other groups

Finally set the group permissions

SPRoleDefinitionCollection roleDef=spW.RoleDefinitions;
SPRoleAssignmentCollection roleAssigns=spW.RoleAssignments;
SPRoleAssignment roleAssign = new SPRoleAssignment(grpOwner);
SPRoleDefinitionBindingCollection definitions=roleAssign.RoleDefinitionBindings;
definitions.Add(roleDef["Full Control"]); //Could be Contribute or Read
roleAssigns.Add(roleAssign);
//Repeat for other groups
spW.Update();