何小碩's profileGet More... ExperiencePhotosBlogListsMore ![]() | Help |
|
September 22 WebPart Connectable LifeCycleThis post describes the lifecycle events of a Sharepoint Connectable WebPart wih a single ViewState backed property; On Page Load
On 1st Postback |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Posted on 19 July 2007 @ 20:07 in #MOSS 2007 If you need to upload a file into a SharePoint document library through code you can get started with this MSDN article: How to: Upload a File to a SharePoint Site from a Local Folder. In case you need to do the upload the file as an attachment to a custom list using the object model, the approach is slightly different. Adding a file to the list item can be done by accessing the Attachments collection of the SPListIem: //code snippet SPList list = web.Lists[new Guid("my list id")]; if (list != null) { web.AllowUnsafeUpdates = true; SPListItem item = list.Items.Add(); item["Title"] = "my title"; if (fileAttachment.PostedFile != null && fileAttachment.HasFile) byte[] contents = new byte[fStream.Length]; SPAttachmentCollection attachments = item.Attachments; } item.Update(); } //snippet end |
Posted by: Asfar Sadewa on: February 23, 2008
Well, not exactly removing, just crippling it so it won’t function. Hahah…
It all began with a guy in another department who got this persistent demand of getting rid of the single file upload button from a SharePoint document library upload menu. “We can upload single file from the multiple one, no need to have a single one.” He claimed. Hahah..
Given that I am a world-class-lazy-bum, I googled, but found that some working solutions applied globally towards the entire site collection, and not strictly to one doclib inside one site. Some claimed they have managed to do so by doing various tricks. But again, due to my acute laziness, I decided not to play around with Features, or even those object models, instead, I resorted to JavaScript.
What I did was described in Lazy 101; detect the Upload Menu by it’s many possible identifier (in this case i use its’ “text” attribute), and brutally disabled it. I cunningly inserted a content editor webpart in the page where the doclib tool bar was visible, and chuckled in an insane glee. Mwhuahahahhahuahahahah …
The script is as below:
<script type="text/javascript"> function GetElementByText(tagName, title) { var a = document.getElementsByTagName(tagName); for (var i=0; i < a.length; i++) { if (a[i].text) { if (a[i].text === title) { return a[i]; } } } return null; } if (window.onload) { var oLoad = window.onload; window.onload = function bodyLoad() { oLoad(); var o = GetElementByText("ie:menuitem","Upload Document"); if (o) { o.disabled = true; } } } </script>
[Update] Hey, guess what, a very kind guy has created a better tool for this (he’s even “featurize” it), check it here
<a href="disp.aspx?ID={@ID}">More...</a>Attachments: <SharePoint:AttachmentsField ControlMode="Display"
FieldName="Attachments" runat="server" Visible="true"/>
[@ID=$ListItemID]
If you’ve been following my blog you know that a bit more than a year ago I’ve published the Imtech Random Image Web Part: a SharePoint web part which allows you to display random images from a list of your choice. The web part I’ve made contains some code which you would have to deploy it in your SharePoint environment to get it working. Did you actually know that you can create the same functionality using no more than a couple of lines of JavaScript and no server-side code at all?
There are two things we need to display random images. First of all an image library with some images in it. It doesn’t matter how many or what kind of images you put in there: it’s okay as long as they are viewable in the browser.
The second thing we need is a Content Editor Web Part which we will use to include the JavaScript which will do the magic for us.
For the purpose of this case I have created a publishing site. The template you choose doesn’t really matter. A WSS3.0 Blank Site would do as well. I’ve uploaded some random photos I’ve found on Flickr to illustrate how it all works.
As soon as the images list is done, let’s proceed to the page.
Let’s start off with putting on the page the List View Web Part of the Images list:
Nothing special here. Now let’s do the magic. Let’s add a Content Editor Web Part, edit it, and paste in the Source Editor the following piece of HTML:
<script type="text/javascript" src="http://ajax.googleapis.com/ajax/libs/jquery/1.2.6/jquery.min.js"></script>
<script type="text/javascript">
jQuery.jQueryRandom = 0;
jQuery.extend(jQuery.expr[":"], {
random: function(a, i, m, r) {
if (i == 0) {
jQuery.jQueryRandom = Math.floor(Math.random() * r.length);
};
return i == jQuery.jQueryRandom;
}
});
</script>
<script type="text/javascript">
$().ready(function() {
var a = $("table.ms-summarystandardbody td.ms-vb2 a:random");
a.parents("div[id^=WebPart]").html('<img src="' + a.attr("href") + '"/>');
});
</script>
What it does? First of all I extend the jQuery framework with the “:random” filter which allows me to pick a randomly chosen element. Then, as soon as the page has been loaded I select all the links from the Images Web Part and pick a random one to display. The last thing I do is to substitute the list of images with the random image I’ve just picked:
That’s all!
Each time you load this page another image will be picked and displayed.
The example I’ve presented is quite simple. Because we’re using a common SharePoint list here, you could store some metadata together with the images and make them appear on the page as well. You could extend the script to add the title, description and maybe even a link to a different site: the sky is the limit.
Providing custom functionality doesn’t necessarily have to mean development and deployment. By just extending the standard SharePoint functionality with JavaScript you can easily create great features which can enhance the overall experience of your application. Using the jQuery framework you can simplify creating these enhancements even more. jQuery covers for you all the basics and allows you to focus on the functionality you to provide to your users.
ref:http://blog.mastykarz.nl/showing-random-images-sharepoint-2007-jquery/
Quote
Sharepoint Marquee Scroll Listings
One of our clients approached us with an interesting idea. I welcomed his request because he was such an ambitious client. Anyway, the request was scrolling the listings of any area. He wanted to display the listings on a marquee tag. While researching it, I couldn't find anything similar on the net, so I thought I’d share this webpart with you .
I created a C# webpart to have the following features :
1- display area listings ordered by the created date (last created first shows)
2- an icon image (e.g. Company logo) separates between listings
Since I have attached the source code of this webpart; you can upgrade the solution to have other feature like:
1- show the top (n) number of listings
2- stop scrolling when mouse over
3- you can set a scroll left/scroll right functions
Here are simple steps to deploy the webpart on your portal
Step 1
Download the the project from here http://cid-c6d240d97b073074.skydrive.live.com/self.aspx/Attachments/MarqueeListings_Zip.zip
Step 2
Go to the bin\Debug where the assembly file of the Marquee listing resides(MarqueeListings.dll) .this dll file has to be dragged and dropped to the GAC
(HD:\WINDOWS\assembly ).
Step 3
Copy the image MarqueeIcon.GIF to the sharepoint images
location : HD:\Program Files\Common Files\Microsoft Shared\web server
extensions\60\TEMPLATE\LAYOUTS\1033\IMAGES
Step 4
The webpart has to be registered as safe control. so copy the following script
<SafeControl Assembly="MarqueeListings, Version=1.0.0.0, Culture=Neutral, PublicKeyToken=78fabca6851eb8f0" Namespace="Sharepoint.Afkar.MarqueeListings" TypeName="*" Safe="True" />
< P Assembly="MarqueeListings, Version=1.0.0.0, Culture=Neutral,
Then add it to the web.config which resides on the virtual directory of your portal
Step 5
Restart IIS.
Step 6
Import the webpart MarqueeGroupedListings.dwp to the portal. The web part displays the grouped listings of the home page of the server . if you want to change to display the listings of another area you need to modify the web part .under the Marquee options write the Url of the area (e.g. http://serverName/Area2)
Step 7
There is no step 7. Its Over!!! But incase you want to display other area's listings you need to edit the webpart properties giving the correct area URL
Code Sample
private const string defaultURL = "";
private string _URL = defaultURL;[Browsable(true),Category("Marquee Options"),
DefaultValue(defaultURL),
WebPartStorage(Storage.Personal),
FriendlyName("Area URL"),Description("Area URL")]
public string URL
{
get
{
return _URL;
}set
{
_URL = value;
}
}
protected override void RenderWebPart(HtmlTextWriter output)
{
try
{
//******************************This section to get the Grouped listings of any area***************
AreaListingCollection areaListings=GetAreaListings(this.URL.ToString());
if (areaListings!=null)
{
if (areaListings.Count>0)
{
string str="";
int counter=0;
ArrayList textArrayList = new ArrayList();
ArrayList linkArrayList = new ArrayList();
//this is order the last one entered appears in the first
int TotalNewNUm=0;foreach (AreaListing areaListing in areaListings)
{
textArrayList.Add (areaListing.Title.ToString() ) ;
linkArrayList.Add (areaListing.URL.ToString() ) ;
TotalNewNUm++;
}//foreach
int i ;
for(i=TotalNewNUm-1 ;i>=0 ;i--)
{
str+= "<a href=" + linkArrayList[i] + " target=_blank > <span style='font-family:verdana ; font-size: 8pt ; height:5px; margin-bottom:3px; '>" + textArrayList[i] + "</span> </a>" ;
counter++;
if (i !=0)
{
str+= "<img style='margin-top:5px;' src='/_layouts/1033/images/MarqueeIcon.GIF' >" ;
}
}output.Write( " <marquee>" + str + "</marquee>" );
}
else
{
output.WriteLine (" There is No listings in this area " + this.URL.ToString() + " !");
}
}
else
{
output.Write ("Wrong area URL, Go back to the webpart properties to correct the area URL (e.g http://serverName:port/areaName)");
}}
catch (Exception ee)
{
output.Write ( "Errorr : " + ee.Message );
}
}
private AreaListingCollection GetAreaListings(string url)
{SPSite siteCollection;
SPWeb site ;try
{
if (url=="")
{
siteCollection = SPControl.GetContextSite(Context);
site = SPControl.GetContextWeb(Context);
}
else
{
siteCollection = new SPSite(url);
site = siteCollection.OpenWeb();
}
TopologyManager topologyManager = new TopologyManager();
Uri uri =new Uri(siteCollection.Url);//new Uri("http://MyPortal");
PortalSiteCollection sites = topologyManager.PortalSites;
PortalContext portalContext = PortalApplication.GetContext(sites[uri]);
Area newsArea = AreaManager.GetArea(portalContext, site.ID);
return newsArea.Listings;
}
catch (Exception ee)
{
return null;
}
}
This Article Published on:
http://ahmadadainat.spaces.live.com
Please drop me an email if you have any comments or enquiries. ahmad.adainat@gmail.com , dont forget to swing by my blog to see my latests.



| <?xml version="1.0" encoding="utf-8" ?> <property name="Description" type="string">Rotates Pictures from a Picture Library.</property> |
| [assembly: AllowPartiallyTrustedCallers()] |
| <SafeControl Assembly="CI.CustomWebParts.Randomize, Version=1.0.0.0, Culture=neutral, PublicKeyToken=3d0e3c375c2b1907" Namespace="CI.CustomWebParts.Randomize" TypeName="RotatingImage" Safe="True" /> |
| using System; // Declarations |
I finally figured it out! This was supposed to be one of those very simple tasks that I should have been able to do without any custom code. Turning a sub-site (or web) into a site collection (or top level site) turned out to be the most difficult task I've yet to face with SharePoint 2007. In theory you should be able to do this using the following commands which could be put into a batch file:
REM Create a test web for exporting stsadm -o createweb -url "http://intranet/testweb" -sitetemplate "SPSTOPIC#0" REM Export the test web to the filesystem stsadm -o export -url "http://intranet/testweb" -filename "c:\testweb" -includeusersecurity -versions 4 -nofilecompression -quiet REM Create a managed path for the new top level site stsadm -o addpath -url "http://intranet/testsite" -type explicitinclusion REM Create an empty site with a default site template (note that if you don't specify a template you have to manually activate the required features) stsadm -o createsite -url "http://intranet/testsite" -owneremail "someone@example.com" -ownerlogin "domain\username" -sitetemplate "SPSTOPIC#0" REM Import the site stsadm -o import -url "http://intranet/testsite" -filename "c:\testweb" -includeusersecurity -nofilecompression -quiet
Unfortunately what you get is only a partially functional site (and in some case not functional at all). There are several errors that you are likely to encounter after running the above using the created testweb or your own existing web. The first and most obvious error is that when you load the default.aspx page of the new site you may get a File Not Found error (note that running the above as is will not give you this error). This is the result of the publishing pages PageLayout URL getting messed up (effectively still pointing to an old value). I addressed this specific issue with a separate command (http://stsadm.blogspot.com/2007/08/fix-publishing-pages-page-layout-url.html) and the I've encapsulated that functionality into the new commands I've created which are detailed below.
The next error you're likely to see is on the Area Template Settings page (Site Settings -> Page layouts and site templates). The specific error is "Data at the root level is invalid. Line 1, position 1".
Anyone who's done a lot of XML work should recognize this error as an XML parsing error. This error occurs if the web you imported from was set to inherit it's page layouts from it's parent. When a web is setup this way there's a property called "__PageLayouts" which gets set to "__inherit".
For a top level site collection this value should always be either an empty string (all page layouts are available) or XML describing which layouts are available. The import operation does not consider this and leaves the value as is thus resulting in the XML error when attempting to parse "__inherit" as XML. The fix for this is simple enough - change the value to an empty string. Unfortunately that's not all we have to do. Fixing the above error results in the page loading without errors, however, the page layouts section does not load. There's still several issues that need to be resolved. If you now go and view the master gallery (Site Settings -> Master pages and page layouts) you should see all the default page layouts. If you have any custom page layouts those won't exist and will cause problems.
Also, if you attempt to edit a file you'll notice that even though we used a publishing template it doesn't prompt you to check the file out. What's more is that once you view the form for a layout you should see that only the core fields are present (no Content Type, Associated Content Type, Variations, etc.).
There are several things that need to be fixed here - first we need to activate all the features that would otherwise be activated on a new site collection (need this so that we can get the publishing workflow options enabled). Second we need to reset all the properties for the gallery to match that of our source gallery (namely we need to allow management of content types).
Third we have to change the ContentType field from being a Text field to being a Choice field (more about this in a minute). Fourth we need to re-associate each file as a Page Layout file by setting all the necessary properties (Content Type, Associated Content Type, etc.). In regards to changing the ContentType field this is the one that caused me the most headache to figure out. For some reason during the import of the site this field gets a bit messed up (note that I'm not referring to the ContentType field that is linked in from the Page content type which is associated with the library but rather another field that is part of the gallery definition itself). The field should be a Choice field with options such as "Page Layout", "Publishing Mater Page", "Master Page", and "Folder". However, during the import the field is converted to a Text field - don't ask me why.
The result is that when you query for the list of available page layouts the unmanaged code that Microsoft uses to do the actual query chokes because it can't find a matching value in the list so it produces an invalid query which will always return no results back. To fix this I copy the source master page gallery on top of the target gallery using the content deployment API. I also found that (with SP2) the PublishingResources feature seemed to correct the issue (at least in the tests that I ran).
UPDATE 9/4/2007: I just discovered that another issue is related to the global navigation. If you view the navigation via the browser it will look as though everything is just peachy but if you attempt to manipulate the navigation programmatically you'll find that the PublishingWeb's GlobalNavigationNodes property is empty (no items are present). This is because the global navigation is stored at the site collection level so when you import the web it does not take the global navigation with it, just the current. The fix is simple enough - just loop through the current navigation collection and copy it to the global navigation collection. This will help to allow other programmatic manipulations of the global navigation to succeed.
UPDATE 7/6/2009: I am now calling the code that I created to copy content types from one site collection to another. This solves issues that can occur if a site collection content type was not created via a Feature. I've also added additional logging to better show what is happening.
So, to summarize the things that need to be repaired after importing into your empty site collection:
Some of the above can be done via the browser but most of it requires programmatic changes. In order to solve all these problems I've created two custom stsadm commands - the first will take a site make all the repairs identified above (so it assumes you've already imported the site).
The second basically just abstracts the whole process of exporting a web, creating a site, importing into the site, and then repairing the site (this way the entire process can be done with just one command). The commands I created are detailed below (forgive the verbosity of the names - I had trouble coming up with something shorter).
1. gl-repairsitecollectionimportedfromsubsite
The code is fairly well documented so rather than discuss it all (there's a lot of it) I've linked it to this post here. The syntax of the command can be seen below:
C:\>stsadm -help gl-repairsitecollectionimportedfromsubsite
stsadm -o gl-repairsitecollectionimportedfromsubsite
Repairs a site collection that has been imported from an exported sub-site. Note that the sourceurl can be the actual source site or any site collection that can be used as a model for the target.
Parameters:
-sourceurl <source location of the existing sub-site or model site collection>
-targeturl <target location for the new site collection>
The following table summarizes the command and its various parameters:
| Command Name | Availability | Build Date |
|---|---|---|
| gl-repairsitecollectionimportedfromsubsite | WSS 3, MOSS 2007 | Released: 9/4/2007 Updated: 7/6/2009 |
| Parameter Name | Short Form | Required | Description | Example Usage |
|---|---|---|---|---|
| sourceurl | source | Yes | The URL to the source sub-site to convert. | -sourceurl http://portal/subsite -source http://portal/subsite |
| targeturl | target | Yes | The URL of the new site collection to create. | -targeturl http://portal/sites/site -target http://portal/sites/site |
Here’s an example of how to repair the site created using the batch file above:
stsadm –o gl-repairsitecollectionimportedfromsubsite –sourceurl "http://intranet/testweb/" -targeturl "http://intranet/testsite/"
2. gl-convertsubsitetositecollection
As stated above, this command is just an abstraction of other commands - it simply calls out to stsadm to do export the site (note that you can provide a previously exported site file/folder), create the managed path, create the empty site, import the site, and finally repair the imported site. As there's nothing spectacular going on here I didn't bother culling the code out in this post (download the project if you're interested in the details). The syntax of the command can be seen below:
C:\>stsadm -help gl-convertsubsitetositecollection stsadm -o gl-convertsubsitetositecollection Converts a sub-site to a top level site collection via a managed path. Parameters: -sourceurl <source location of the existing sub-site or model site collection> -targeturl <target location for the new site collection> -owneremail <someone@example.com> [-createmanagedpath] [-haltonwarning] [-haltonfatalerror] [-includeusersecurity] [-suppressafterevents (disable the firing of "After" events when creating or modifying list items)] [-exportedfile <filename of exported site if previously exported>] [-nofilecompression] [-ownerlogin <DOMAIN\name>] [-ownername <display name>] [-secondaryemail <someone@example.com>] [-secondarylogin <DOMAIN\name>] [-secondaryname <display name>] [-lcid <language>] [-title <site title>] [-description <site description>] [-hostheaderwebapplicationurl <web application url>] [-quota <quota template>] [-deletesource] [-createsiteinnewdb] [-createsiteindb] [-databaseuser <database username>] [-databasepassword <database password>] [-databaseserver <database server name>] [-databasename <database name>] [-verbose] |
The following table summarizes the command and its various parameters:
| Command Name | Availability | Build Date |
|---|---|---|
| gl-convertsubsitetositecollection | WSS 3, MOSS 2007 | Released: 9/4/2007 Updated: 7/6/2009 |
| Parameter Name | Short Form | Required | Description | Example Usage |
|---|---|---|---|---|
| sourceurl | source | Yes | The URL to the source sub-site to convert. | -sourceurl http://portal/subsite -source http://portal/subsite |
| targeturl | target | Yes | The URL of the new site collection to create. | -targeturl http://portal/sites/site -target http://portal/sites/site |
| owneremail | oe | Yes |
The site owner's e-mail address. Must be valid e-mail address, in the form someone@example.com. |
-owneremail someone@example.com -oe someone@example.com |
| createmanagedpath | createpath | No | Create a new managed path for the site collection. | -createmanagedpath -createpath |
| haltonwarning | warning | No | Stop execution of the command if a warning event occurs during the export or import process. | -haltonwarning -warning |
| haltonfatalerror | error | No | Stop execution of the command if a fatal error occurs during the export or import process. | -haltonfatalerror -error |
| exportedfile | file | No | Use a previously exported site (created using stsadm's export command). | -exportedfile c:\exportdata\site -file c:\exportdata\site |
| nofilecompression | No | Do not compress the site when exporting (or if previously exported use an uncompressed file for the import). | -nofilecompression | |
| ownerlogin | ol |
If your farm does not have Active Directory account creation mode enabled, then this parameter is required. This parameter should not be provided if your farm has Active Directory account creation mode enabled, as Microsoft Office SharePoint Server 2007 will automatically create a site collection owner account in Active Directory based on the owner e-mail address. |
The site owner's user account. Must be a valid Windows user name, and must be qualified with a domain name, for example, domain\name |
-ownerlogin domain\name -ol domain\name |
| ownername | on | No |
The site owner's display name. |
-ownername "Gary Lapointe" -on "Gary Lapointe" |
| secondaryemail | se | No |
The secondary site owner's e-mail address. Must be valid e-mail address, in the form someone@example.com. |
-secondaryemail someone@example.com -se someone@example.com |
| secondarylogin | sl |
If your farm does not have Active Directory account creation mode enabled, then this parameter is required. This parameter should not be provided if your farm has Active Directory account creation mode enabled, as Microsoft Office SharePoint Server 2007 will automatically create a site collection owner account in Active Directory based on the owner e-mail address. |
The secondary site owner's user account. Must be a valid Windows user name, and must be qualified with a domain name, for example, domain\name |
-secondarylogin domain\name -sl domain\login |
| secondaryname | sn | No |
The secondary site owner's display name. |
-secondaryname "Pam Lapointe" -sn "Pam Lapointe" |
| lcid | No |
A valid locale ID, such as "1033" for English. You must specify this parameter when using a non-English template. |
-lcid 1033 | |
| title | t | No |
The title of the new site collection (this value will be overwritten when the site is imported - it is available only to help in situations in which the import fails). |
-title "New Site" |
| description | desc | No |
Description of the site collection (this value will be overwritten when the site is imported - it is available only to help in situations in which the import fails). |
-description "New Site Description" -desc "New Site Description" |
| hostheaderwebapplicationurl | hhurl | No |
A valid URL assigned to the Web application by using Alternate Access Mapping (AAM), such as "http://server_name". When the hostheaderwebapplicationurl parameter is present, the value of the url parameter is the URL of the host-named site collection and value of the hostheaderwebapplicationurl parameter is the URL of the Web application that will hold the host-named site collection. |
-hostheaderwebapplicationurl http://newsite -hhurl http://newsite |
| quota | No |
The quota template to apply to sites created on the virtual server. |
-quota Portal | |
| deletesource | No | Delete the source site after conversion (only recommended if significant testing has occurred). | -deletesource | |
| createsiteinnewdb | newdb | No | Create the site collection in a content database. | -createsiteinnewdb -newdb |
| createsiteindb | db | No | Create the site collection in an existing content database. | -createsiteindb -db |
| databaseserver | ds | No | The database server containing the specified content database. If not specified then the default database server is used. | -databaseserver spsql1 -ds spsql1 |
| databaseuser | du | No |
The administrator user name for the SQL Server database. |
-databaseuser domain\user -du domain\user |
| databasepassword | dp | No |
The password that corresponds to the administrator user name for the SQL Server database. |
-databasepassword password -dp password |
| databasename | dn | Yes if createsiteinnewdb or createsiteindb is specified. |
The name of the content database to put the site collection in (will be created if createsiteinnewdb is specified). |
-databasename SharePoint_Content1 -db SharePoint_Content1 |
| suppressafterevents | sae | No | Disable the firing of After events when creating or modifying files or list items during the import. | -suppressafterevents -sae |
| verbose | v | No | Displays logging information when executing. | -verbose -v |
Here's an example of how to do all that the batch file above is doing (minus the creation of the testweb) as well as the repair operation all with one command:
One area of improvement may be to pull the owner and secondary owner information from the source site collection so that this information does not have to be provided - maybe I'll do that if I feel I have the time or if people express enough interest. Note that you can specify a title and description but they'll be overwritten during the import - I only included them so that if the import fails and you're left with an incomplete site you'll at least have a name for it if you should forget to delete it and stumble upon it a year later.stsadm –o gl-convertsubsitetositecollection –sourceurl "http://intranet/testweb/" -targeturl "http://intranet/testsite/" -createmanagedpath -nofilecompression -owneremail "someone@example.com" -ownerlogin "domain\user" -deletesource
Figuring out how to solve all the issues surrounding converting a web to a site collection was a real pain the a$$ so any feedback that people have on this would be greatly appreciated - hopefully if there are others out there that have stumbled on this then they'll benefit from it as well. Keep in mind also that though I think I've solved all the errors related to the conversion it's possible that different implementations may have additional errors that I have not seen - if that's the case please let me know (especially if you've solved the problems) so that I can share with others.
Update 9/21/2007: I've fixed a couple minor bugs that pop up when converting a non-publishing site. I've also enhanced the command to take advantage of another new command I created: gl-updatev2tov3upgradeareaurlmappings (updates the url mapping of V2 bucket webs to V3 webs thereby reflecting the change of url as a result of the move so if a user tries to hit the V2 url it will redirect to the new and updated V3 url).
Update 10/2/2007: I've enhanced the command to take advantage of another new command I created: gl-retargetcontentquerywebpart (fixes Grouped Listings web parts that remained pointed at the old list rather than the newly imported list).
Update 10/12/2007: I've removed the retainobjectidentity parameter. If you attempt to use this parameter you will receive a syntax error. Turns out that retaining the object identity when going from a sub-site to a site collection just created a nightmare. However, because I still had to handle these web parts that were broken I decided to enhance the repair routines to manually retarget the DataFormWebPart and ContentByQueryWebPart web parts. So if a matching list can be found on the source then any of these web parts on your pages should be fixed so that you don't have to manually fix them (the gl-repairsitecollectionimportedfromsubsite command will do the same).
Update 7/6/2009: I removed the direct DB access code and added support for copying content types from the source.
Posted by Gary Lapointe at 9:11 AM
Do you want to save about 500kb traffic for every anonymous request to your MOSS 2007 Publishing Site?
There is no default way in MOSS 2007 where you can say: "I'm online visible for anonymous users, I don't want to load core.js, portal.js, init.js, ... every time a user is accessing a page". I was searching for this switch a long time, but it doesn't seems to exist.
Microsoft's proposal for this is to force a delayed loading of the core.js, which can be read here: http://support.microsoft.com/kb/933823/en-us or here: http://blogs.msdn.com/ecm/archive/2007/02/21/building-a-new-page-layout-which-does-not-reference-core-js-but-downloads-it-while-the-page-is-being-viewed-thereby-optimizing-response-time.aspx. This doesn't solve the problem, but is one way to speed up your pages.
A solution for this problem is a HTTP-Filter. This filter can be deployed in the /bin directory of your web application and has to be referenced in your web.config.
The solution below is not perfect, but it works and saves a lot of traffic, server load, time and money. And it enables you to publish lightweight pages with MOSS 2007.
Improvements for the code below would be a separation of the "tags to cleanup" in a configuration file and the usage of regular expressions. But with output cache enabled, this shouldn't be a performance issue.
Make sure to adapt this code for your own needs, as I'm removing e.g. ViewState and so on, which could possibly crash your MOSS applications.
MOSSCleanupModule.cs:
using System;MOSSCleanupFilter.cs:
using
System;web.config:
<
httpModules>
ref:http://www.ie-soft.de/blog/PermaLink,guid,968b0588-f306-467b-be51-54f7a8f2079d.aspx
If you add inline code to your e.g. PageLayout in MOSS 2007 you will get the following error: "Code blocks are not allowed in this file".
To avoid this problem, add the following code block to your web.config:
<PageParserPaths>
<PageParserPath VirtualPath="/" CompilationMode="Always" AllowServerSideScript="true" IncludeSubFolders="true" />
</PageParserPaths>
This will allow inline code in your entire site collection. Make sure to be aware with security issues and inline code. To enable inline code only for a single file use:
<PageParserPaths>
<PageParserPath VirtualPath="/Pages/MyPage.aspx" CompilationMode="Always" AllowServerSideScript="true" />
</PageParserPaths>
ref:http://www.ie-soft.de/blog/PermaLink,guid,cb97a3df-6725-468c-97fa-725e2c4ceb4c.aspx
Okay, this one took me a while to figure out, but nonetheless I found it and will share it.
In order to turn off or disable the MySite or MyLinks functionality you need to be an Sharepoint administrator.
Go to the Central Administration Web Page
Click on the link for Shared Services Administration
--If you have more than one SSP, select the one that is running the MySites functionality
Under "User Profiles and My Sites" click Personalization Services Permissions
Select the group you want to limit the functionality for. More than likely you will just have NTAuthority\Authenticated Users.
In the next screen you will see a list of checkboxes,
--To disable MySites uncheck "Create Personal Site"
--To disable MyLinks uncheck "Use Personal Features"
Once you find it, disabling the functionality is pretty easy, but if you are new to 2007 like I am it will take a while to find. Hopefully this will save you a few cycles.
ref:http://geekswithblogs.net/RogueCoder/archive/2006/11/01/95766.aspx
A rather long title for this post, but that's what it comes down to.
Suppose you want to access controls in the same Web Part on the client side using JavaScript. For instance, you have two DropDownLists placed on a Web Part and you want to fill the second one dynamically based on the selected value of the first DropDownList – a simple master/detail type of control. Postbacks are no option here since a selection change of the upper DropDownList shouldn't bother the server and delay business process by having the user to wait for the result. An Ajaxy approach may also be interesting, but out of the scope of this posting.
I've been struggling with some problems an couldn't find anything about this issue on the web, so I decided to post my findings.
Because it is possible to place a Web Part multiple times on a SharePoint web page, SharePoint Server will assign a unique identifier to each control (that is, a Web Part and some of its child controls¹) to be able to distinguish between Postbacks originating from different Web Parts. The unique ID can be found in the ID attribute of a HTML element and looks similar to this:
TopZone_g_d72e1f89_87e6_4f08_b6c5_165dc560ce8a__ctl1
TopZone defines the location of the Web Part, along with its GUID. The bold part (_ctl1) denotes the ID of the control in question, a SELECT in my case.
The JavaScript code to add an onchange event handler to the master control looks like this:
master.Attributes.Add("onchange", String.Format("setDetail(document.getElementById('{0}'));", detail.ClientID));
However, this will not work: The location and the GUID of the Web Part is evaluated when the page is rendered. These values then serve as a prefix to the control ID (_ctl1) you set in your own code. You have to retrieve the location/GUID prefix along with the control ID and combine them to the actual HTML ID. Because Web Parts should derive from Microsoft.SharePoint.WebPartPages.WebPart this is pretty easy to achieve.
// Combine the Web Part's ID and the control ID.
master.Attributes.Add("onchange", String.Format("setDetail(document.getElementById('{0}_{1}'));", base.ClientID, detail.ClientID));
Quote
SharePoint Usage Analytics
We must enable usage analytics to measure our SharePoint site usage and performance through the Site Usage Reports and Site Collection Usage Reports of Microsoft Office SharePoint Server 2007 or through Site Usage Reports provided by Microsoft Office SharePoint Designer 2007.
In Windows SharePoint Services 3.0/Microsoft Office SharePoint Server 2007, the following are the usage analytical reports:
Site Usage Reports:
1. Site Usage Summary
2. Requests
3. Users
4. Referrers
5. Destination Pages
Site Collection Usage Reports:
1. Site Usage Summary
2. Requests
3. Users
4. Referrers
5. Destination Pages
6. Search Queries
7. Search Results
The Microsoft Office SharePoint Designer 2007 provides the following SharePoint usage reports:
1. Usage Summary
2. Page Hits
3. Visiting Users
4. Operating Systems
5. Browsers
6. Referring Domains and URLs
7. Search Strings
To enable usage analytics, we need to perform the following:
1. Enable Windows SharePoint Services usage logging
2. Enable the usage reporting shared service
3. Activate the reporting feature
That's it! Thanks...
Our main service is providing nearshore outsourcing to customers around the globe. It is very important for us to track effort spent as much detailed as possible, and report it to our customers, usually on a weekly basis.
After trying with other tools and not being 100% satisfied, we decided to take advantage of Microsoft tools and start using Project Server 2007 for time management here in our company.
I spent some hours doing research about this topic, and I found different articles and posts explaining just one chapter at a time, without finding a complete guide to install and configure this tool for this particular goal.
Even after we followed all the steps found around several sources, we were still not able to generate the reports with the time spent by the resources selected for this pilot, due to some issues with the browser and also with the Cube (Project integrates with Analysis Services) used for populating the data.
Then after several hours of effort with one of our Senior developers, we had our Project Server running and some of our team members were able to enter their timesheets using Project Web Access, a web interface exposed by this technology.
Using Project Server also enabled us to integrate Sharepoint workspaces for centralizing project documentation, risks, issues and tasks, with project schedule, costs and time management that we can also publish through web so our customers can have a snapshot of the project anytime. We can generate customized reports through Pivot Tables and Analysis Services integration.
Having this said, this is a powerful tool with a complete set of features, ideal for small, medium or enterprise organizations. Some features such as the web interface are really helpful for our nearshore software development practice, enabling both customers and remote teams to access the data everywhere.
These are the steps you should follow in order to install and configure Project Server 2007 for timesheet management:
1. Install Sharepoint Server 2007 in a brand new Virtual Machine with Windows Server 2003.
Step by step and different deployment scenarios can be found here: http://technet.microsoft.com/en-us/library/cc197758.aspx#section2
2. After installed, the project web access is located in a url like http://servername:port/PWA
3. Add a few domain users to the Project Server using the Server Settings / Security / Manage Users link.
4. Add your team members into Project Server resources list, using the Resources Center. These will be the team members you will allocate to each project and task.
5. Even when you can do almost everything from the Project Server web interface, it is faster to use your desktop version of Office Project 2007 to create projects, tasks and allocate resources. This requires the PM to have MS Office Project 2007 Professional version installed (Standard doesn´t support it)
6. To connect your Office Project to the Project Server 2007, you need to configure it through the Enterprise Options under the Tools menu.
7. Create a test project using the Project Center link / Add Project.
8. After adding a few test tasks, you must assign the team to the project and each task. This will allow the team members to see the assigned tasks and
a. Go to Build Team From Enterprise
b. Select the task(s)
c. Go to Assign Resources
d. Select the resources you want to assign. You can set costs and effort allocated.
9. Project Server requires timesheets periods to be defined (in most of the cases these will be mapped to each week of the year). You should go through each link in the Timesheets section under the Server Settings section.
There is a complete ebook for this topic which you should download and read from here http://technet.microsoft.com/en-us/library/cc197478.aspx
10. Once the timesheets periods have been defined, your team member should be able to view the assigned tasks after login into the PWA with his credentials.
11. Each resource will be responsible for creating the timesheet and reporting it. The timesheet can be populated with the assigned tasks, or can be blank and then populated using the Add New Line link
12. Resource should submit his timesheet. These will be usually automatically approved unless you configure it. The timesheet cannot be updated except for the admin, once it is submitted.
Once all of this is done, the database will have the data but you won´t be able to retrieve it using the reports yet.
First, you need to configure this feature, otherwise you will see just a blank page when clicking the Data Analysis link
In order to configure the Reports follow these steps:
1. Go to Create Server Settings, Views, New View, and select Data Analysis as the view type
2. Select your Data Analysis Services. If is it not populated you should go to check if Analysis Services was installed and all services are running.
3. Configure the settings and the data view properties (just follow the sections in the screen)
4. Configure the fields you want to display in the default timesheet view
5. Add the project server URL to the list of Local Intranet sites in your browser settings.
6. Configure your browser settings to allow ActiveX.
7. Configure your browser settings to allow Data Sources across domains.
And that´s all!
So if you follow these steps then you will be able to take advantage of Project Server reporting features:
I hope this guide is useful and ping us if you face any issues when using this powerful tool !
So far we are really satisfied with it.
Post written by - Marcelo Lopez, Project Manager @ UruIT Global IT Services
Note2: Only works with MOSS 2007 sorry as you WSS guys do not have audiences targeting
This is my small contribution to the SharePoint world. It is a web part that once added to a web part page, allows you to customise the display by adding JavaScript to selectively hide controls on the page . Ever needed to hide a field from display/edit for a certain audience? Well here is a way do it without requiring SharePoint Designer and having to break a page from it’s site definition (unghosting).
Before and after shots below (look ma - no top button!)
To fully understand what is being done here, I suggest you read my series of articles on the use of JavaScript in SharePoint. Part 3 in particular will show you how to safely add this web part to pages with editing disabled (NewForm.aspx, EditForm.aspx and DispForm.aspx)
The full series can be found here: Part 1, Part 2, Part 3, Part 4, Part 5 and Part 6.
Kudos to Jeremy Thake for feedback and some code contribution. Despite being seriously metrosexual, he is otherwise otherwise very cool :-P.
Now two important warnings:
Warning 1: This is an alpha quality release and I may never touch it again
So you very likely *will* break it. If there is enough interest, I am happy to pop it on codeplex
Warning 2: This web part should NOT be considered as a security measure and thus used in any security sensitive scenario (such as an extranet or WCM site). JavaScript by its very nature can be trivially interfered with and thus other methods (server side) should be employed in these scenarios to prevent interference at the browser.
You can download by reading the disclaimer and clicking the button below..
THIS CODE IS PROVIDED UNDER THIS LICENSE ON AN “AS IS” BASIS, WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING, WITHOUT LIMITATION, WARRANTIES THAT THE COVERED CODE IS FREE OF DEFECTS, MERCHANTABLE, FIT FOR A PARTICULAR PURPOSE OR NON-INFRINGING. THE ENTIRE RISK AS TO THE QUALITY AND PERFORMANCE OF THE COVERED CODE IS WITH YOU. SHOULD ANY COVERED CODE PROVE DEFECTIVE IN ANY RESPECT, YOU (NOT THE INITIAL DEVELOPER OR ANY OTHER CONTRIBUTOR) ASSUME THE COST OF ANY NECESSARY SERVICING, REPAIR OR CORRECTION. THIS DISCLAIMER OF WARRANTY CONSTITUTES AN ESSENTIAL PART OF THIS LICENSE. NO USE OF ANY COVERED CODE IS AUTHORIZED HEREUNDER EXCEPT UNDER THIS DISCLAIMER
Use at your own risk!
To install perform the following commands
To remove/reinstall perform the following commands
ref: http://www.cleverworkarounds.com/2008/03/13/free-mosswss-2007-web-part-hide-controls-via-javascript/
SharePoint development environment configuration depends on the processes, type of engagements and type of work. The most popular solution that addresses the development scenarios is using local SharePoint farm, separated from the production servers, with the single installations of the SharePoint server on the development boxes. This provides isolation for builds, tests, and debugging across different teams, projects and production environments. The local environment is mostly isolated by development box and is installed on the host server or on virtual server. The following procedure is an overview of the steps that are required to create a typical SharePoint development environment.
Development Box installation
Chose development tools
There are varieties of tools that can make development fast and easy - from commercial to open source and Microsoft products.
Microsoft recommends to use “Visual Studio extensions for Windows SharePoint Services” (VSeWSS), which simplify code-up solutions for SharePoint (e.g. Web Parts, List Definitions, Site Definitions, etc) via UI and allows reverse-engineering existed site to extract definitions for SharePoint entities.
The disadvantages of VSeWSS are:
1) not intuitive for beginners;
2) doesn’t provide usability to change all properties of the features, and other SharePoint items easily
3) Cannot use VSeWSS projects without VSeWSS extension.
Others 3-rd party tools, which simplify development, are:
1. Management Tools
• SharePoint Spy (http://www.echotechnology.com)
• SharePoint Manager (http://www.codeplex.com/spm)
• SharePoint Analyser (http://community.bamboosolutions.com)
These tools help to manage services of SharePoint farm and get detailed information about configuration settings.
For example, screenshots of SharePoint Analyzer (left) and SharePointSpy (right)

2. Visual Studio Tools
• STSDev to create project files (http://www.codeplex.com/stsdev)
• SPSource to get site sources (http://www.codeplex.com/spsource)
These tools create Visual Studio projects with the SharePoint 12-hive structure, and provide build settings to build/deploy/retract WSP packages directly from IDE. STSDev is the best tools to create a variety of projects - from simple features and Web Parts to Custom Workflow projects:

3. Development Tools
4. Other Tools
• U2U CAML Builder - editor for CAML queries (http://www.u2u.net)
• SharePoint Feature - set of different development and debugging plugins (http://www.codeplex.com/features)
Such tools give your additional flexibility in everyday development stuff, providing different editors, log viewers and analysers to make SharePoint development easier and faster.
Setup Deployment environment
Configure Continuous Integration (CI) system to build SharePoint solution, compile output to WSP packages, prepare deployment scripts and deploy WSP to Test Environment. Team Foundation Server (TFS) is one of the recommended tool for this task. There are several articles describing how to adopt SharePoint solution for CI, setup builds and configure TFS Deployer to deploy SharePoint packages across different environments:
http://www.azsharepointpros.com/ShareAndEnjoy/Lists/Posts/Post.aspx?ID=10
As to SharePoint Visual Studio Templates, CodePlex has a “SPTemplateLand” project that provides “12-hive” structure for SharePoint projects and deployments.
This solution was slightly modified by Microsoft SharePoint Consulting Services guys to have single deployment package for multiple projects and support packaging additional SharePoint Artefacts (site definitions, root files). This project is published there http://blogs.msdn.com/gderun/archive/2008/01/11/sharepoint-visual-studio-project-and-deployment-templates.aspx
Configure testing environment
The following diagram depicts the most common development environment, which is recommended by “SharePoint Guidance patterns & practices” team.

The staging environment represents the target production environment as closely as possible from the perspective of topology (for example, the server farm and database structure) and components (for example, the inclusion of the Microsoft Active Directory service and load balancing, where applicable).
|
|