While working on a client's MOSS 2007 Publishing site, we ran into an issue where we simply couldn't create any CMS pages. After clicking Site Actions -> Create Page, the page would act like it was posting back and, after a several minutes, would either time out, or prompt me for my credentials 3 or 4 times in a row only to finally display a "You are not authorized to view this page" error. The same happened when attempting to create a page from clicking "New" in the Pages library, clicking "Create" on the View All Site Content page then clicking Publishing Page, or clicking New on the Mangage Content and Structure page while in the Pages library.
This all started happening after I went into Site Settings -> Page Layouts and Site Templates (under the Look and Feel section) and modified which Page Layouts were available for the user to select when creating a new CMS page. Figuring the issue lied in this change of settings, I tried to go back into the Page Layouts and Site Templates settings page again, only to discover it was acting the same way as the Create Page function.
Having no error information to go against and nothing useful coming from the bumped up logs (except an unknown lockfile error which we can't even be sure was linked to our issue), we took a shot in the dark that our issue was permissions related. The user we used to change the Page Layouts and Site Templates settings was a Farm Administrator, Site Collection Administrator, and had Full Control on the particular site we were on, not to mention the fact that we were able to change the Page Layouts and Site Templates settings with this user in the first place. However, we logged in with the System Account and voila!!, we were able to create a CMS page AND access the Page Layouts and Site Templates page.
Ever go into a meeting where clients have asked you questions that you didn't know the answer to? No, that's never happened to me either. But a friend of mine thought every time he went into a meeting where a client asked him a (sensible) question he didn't know the answer to, he would list it here so that others could ponder the answers.I'll list the answers if I find them - Whoops - I mean if he finds them.
- Can the mysites left hand side nav contain different items by default on creation?
- Can you prevent users from creating subsites under my sites?
- Apparently yes - http://www.sharepointblogs.com/tbaginski/archive/2006/11/14/how-to-prevent-creation-of-sub-sites-within-moss-2007-my-sites.aspx
- Can you change the users display name?
- Yes. - http://www.21apps.com/sharepoint/user-profiles-why-do-my-changes-not-show-in-other-sites/ Basically just need to change or remap the name field in user profile properties in Central Admin.
- Once users are imported from AD, can you clear them all out?
SharePoint out of the box supports only one way replication of user from AD to SharePoint which ofcourse means that when users update their profiles in their Mysites it doesn;t get replicated back to AD.
Even worse, their properties can get overwritten during the next profile import from AD.
The 2 recommended methods for updating AD from SharePoint that I have heard of are..
- Microsoft Identity Lifecycle manager
- Bamboo Solutions User Sync
From my little research the Bamboo Solutions seems to be a lot better. - ee review here - http://www.sharepointreviews.com/component/content/article/50-user-management/102-User-Profile-Sync-Web-Part-by-Bamboo-Solutions.html
ILM requires creating an import file from SharePoint - Already sounds too complicated if you ask me.
If anyone has experience with this, I would love to hear some feedback.I will probably end up using the Bamboo Solution so will be able to provide some feedback soon.
In part 1 we looked at creating a Staff Directory using the User
Information List. This time we'll attempt it with the People Search.
begin with obviously we need to be able to search find people using the
search. I have already set up a site using the Search Center site
template. The only problem is I am getting no results when searching
I followed these instructions. - http://groups.google.com/group/microsoft.public.sharepoint.portalserver.development/browse_thread/thread/6f01af3e9da9e0b2/3caa0e3d6d1237c1
and it now works.
The first thing we can explore is what happens when we click edit on the page. Remembr that the search results page is actually a publishing page which is why it sits in a /pages directory.
Looking at this page in edit mode can provide some insight into what all those search web parts in the web parts gallery do. The capabilities of this page are beyond the scope of this article but will definitely be revisited in another article.
One of the requirements of the staff directory is that users should be able to click on a letter like this..
This was easily achieved by modifying the script found here - http://www.ramonscott.com/wordpress/?p=8
to look like this.
peoplesearch.txt (1.85 kb)
Next we want to customise the layout of the search results themselves. As with most of the web parts you will need to edit the XSL. Before you do though note that there appears to be a bug that throws an error every time you edit the XSLT. You can ignore it but unfortunately you can't see any changes you make until you publish the page. More info here - http://www.sharepoint-tips.com/2007/04/error-item-with-same-key-has-already.html
Instructions on customisation can be found here - http://www.sharepointology.com/development/customize-the-people-search-results-part-1/ and here - http://www.sharepointology.com/development/customize-the-people-search-results-part-2/
I was going to provide some of these instructions myself but these articles explain them really well.
Just to add a few finishing touches we can adjust the search dropdown options by mofidying propeties of searchbox.
I added favourite Cake and it now looks like.
Staff directories are a very common request for Intranets. Oddly SharePoint doesn't have a feature called Staff Directories but it contains many bits and pieces that can help build one.
i.e People Search, Custom user properties, My sites, People and Groups page.
There are also out of the box solutions that you can purchase from http://www.bamboosolutions.com such as http://store.bamboosolutions.com/p-41-user-directory-web-part-release-14.aspx
Or you can write code such as http://blogs.syrinx.com/blogs/sharepoint/archive/2007/10/05/sharepoint-2007-face-book-web-part.aspx
This article is to demonstrate how far we can go with just out of the box configuration trying various methods.
Method 1 - Using the User Information List
################### Read this First ################################
Before you try this at home, please note that this solution is very limited. I am making notes as I attempt various methods and these articles are my findings not neccesarily the best solutions.
A better solution is found in part 2 of this article - http://blog.sharepointsydney.com.au/post/Creating-a-staff-Directory-in-SharePoint-Part-2-People-Search.aspx
Pros of this method
Very easy to set up
- Does a good basic job
- Some decent styles and info available OOTB
- Can't create own styles
- Content doesn't synch with SharePoint Profiles (This may be fixable with Bamboo Solutions User Sync)
- As users are removed from SharePoint they still remain in this list (This may be fixable with Bamboo Solutions User Sync)
- Can't edit the page that results appear on. E.G Can't add web parts.
- Can't search for users. Can only group by SharePoint groups.
- When users update their details in MySites it takes a while for the UIL to reflect the changes. This is because syncing is done by a Timer Job called "Profile Synchronization" which runs by default once an hour.
More info: http://sharepointsherpa.com/2008/01/31/employee-directory-using-user-information-list-in-sharepoint-2007/
As part of the experiment I will use the Personalization Site Template
to create a dedicated Staff Directory site for no particular reason
other than I want to see what this site template does.
So here is what the new site looks like. It is just a normal site but it contains a couple of filters preloaded on the page. It also applies a link to this area directly to the creators mysites section.
Now let's go to the People and Groups page and see what our options are.
In this image you can see that I have actually jumped a few steps ahead.
Really all that I have done is created a few groups - Sales, Marketing etc. Under Settings -> 'Edit Group Quick Launch' you can define which groups to show in the Quick Launch on the left.
In our example the client would like to be able to browse by department so we can either create groups to represent each department or perhaps these departments already exist if you are using AD.
Next notice in the top right dropdown that we have created a new view called Staff Directory. You could create as many views as you like perhaps even filtering by location. Or alternatively instead of using the groups in quick launch you could use the views to filter by dept instead.
Note: For some reason list settings option only appears from the top level site which is where you go to create custom views.
Here is where we start the limitations of this approach. You can create a new view but the properties that are displayed in that view seem to be limited to these.
Not sure at this point if you can add more. This may not be a huge limitation as all we areally want this view fo ris to display some basic info about the users and if they want more they can really click through to the user MySite page.
The other bit of customisation for this view is that you can select different styles for displaying the info.
I'm trying to find if you can create your own styles but can't find any info.
You can open any of the views of the UIL from SharePoint Designer by opening the root site but the only options available appear to be the same as you get from the browser view.
On thing I noticed is that a ListViewWebPart is used to display the info but can't find any info on editing styles for LVWP either.
At this point this solution is not looking flexible enough for me so I am abandoning it and moving onto trying the People Search instead in part 2 of this artilce.
I was trying to format the layout of the Custom Query Webpart similar in fashion to instructions found at http://www.heathersolomon.com/blog/articles/CustomItemStyle.aspx.
The problem was that no matter what I did in CQWP based on the announcements list the title and image appeared but the body text was not showing up.
After reading a few articles including http://martijnmolegraaf.blogspot.com/2008/12/configuring-and-customizing-content_20.html I realised that body was a custom field and so I needed to export the webpart.
Edit the exported webpart file with all my custom fields.
The line to edit looked like
<property name="CommonViewFields" type="string">
Note the name followed by datatype.
Then import the webpart back in and use it as you would any other CQWP.
Editing skins with designer can be frustrating due to the many quirks in the process.
For a good starting point read here - http://www.sharepointblogs.com/tigirry/archive/2007/07/27/easy-way-of-editing-customized-theme-in-moss-2007.aspx
Some additional tips.
After you edit CSS files don't swich themes until you copy all your changes back to the theme.css file in the 12 hive otherwise SharePoint will overwrite your changes.
Every time you change themes SharePoint puts a local copy of the theme folder copied from the 12 hive which overwrites the current themes folder.
Only 1 theme folder per site collection appears in Designer.
Also as an extra note in the Masterpage section of sesttings, the system Masterpage option is used for the document center masterpage.
It appears the difference between the SIte Master Page and System Master page is primarily the quick launch. Which becomes the treeview in the System Page.
There are many articles on how to do SharePoint development on an XP pc. E.G http://fernandof.wordpress.com/2008/02/11/how-to-install-the-sharepoint-2007-vs-2005-extensions-on-a-workstation/
The question is does this give you the same experience as the recommended method of developing directly on a SharePoint server?
The bottom line is NO. The reason is that these methods still won't allow you to connect to a SharePoint web.
i.e Anything like this won't work
this._Web = SPContext.Current.Web; or
this._Web = new SPSite(http://<IP_ADDRESS>).OpenWeb();
In other words you can compile but to see the results you will have to deploy to a SharePoint server.
The only exception to this rule is with web parts where code doesn't actually interact with the SharePoint object model and is just a standalone web part. Then you can test your web part by creating a web project with web part zones and run your web part from there.
If that hasn't put you off here are a couple of extra steps you may need to get going with SharePoint dev on XP.
1) Copy all the DLLs out of the GAC of SharePoint install.
So, to extract these DLLs (for example in the c:\temp folder), I use a classic XCOPY command in command line from the folder C:\windows\assembly\ :
XCOPY GAC_MSIL c:\temp /
Then use a normal windows search to find all dll in temp folderabd copy out the SharePoint related ones.
Copy the DLLS to your local GAC. i.e to C:\windows\assembly
Do an IISRESET.
2) If you get a personalization web.config error when testing we parts in local web part zone enabled Site
Make sure you set personalization on your web part manager off for testing locally
<asp:WebPartManager ID="uiWPManager" runat="server" Personalization-Enabled="false"></asp:WebPartManager>