There are situations where it is useful to link data in one list to another list.  For example, if you have a list of projects and a list of tasks.  Some of the tasks are going to be associated with a project.  You can easily create a reference to the project list from items in the task list.

I’m going to assume you have your two lists created; for this example I used two custom lists, but that isn’t necessary.  On your list you want have a reference (the task list in my example) you need to add a lookup column:

First you need to go to the settings for the list that you want to reference the other list.  In my example this is the tasks list

Next you need to create the new column in the list.

This new column needs to be a Lookup column.  This will allow you to select your other List in the “Get information from:” box.  You can see I have selected the ProjTest list I created for this example.   You also need to specify which column in the list that you want to key on.

This is the only way so far that I have found to reference one list from another list.  One work around is to add a single line of text column and have the user input a link to the list view that you want.  I would like a way to reference another list or list view without user input.

In my last post I mentioned that it would be nice to be able to use a security group in other site collections.  This was so that I wouldn’t have redundant security groups to provide access to the Web Part on the home page and to the actual site.  It turns out that these groups cannot be shared across site collections or web applications, but they don’t need to be. 

If you create a new site from an existing site (by going to Site Actions-> Create Site) it will inherit all of the security groups from the parent site.  Doing this pushes security settings down through the site collection tree; people who have access to the parent page will have access to the child.  Microsoft suggests that if you don’t want this behavior then you should just create a separate site collection; however, we can override this behavior.

I did not want to have the groups that I set up for my main site have permissions to every site that I create.  In fact, I wanted the lower level sites to have more granular permissions, and then use those on the main page to change the look based on who is logged in.  To do this, it seems that I have to override the inheritance structure.  Overriding this allows me to add new groups to the children sites that have access to the site but don’t get applied to the other children sites.  To do this:

1. Go to the Site Settings of the child site, then to People and Groups
2. Go to “Site Permissions” and then click Actions->Edit Permissions.  This will pop up a message box telling you that changes to the Parent site will no longer affect this site.  This means that your Parent site’s permissions need to be completely set up before you start this process.
3. Next, go to New->New Group.  On this page you can give this group the permissions you want it to have for this site.  If you tried to create a new group before the last step you would not have been able to give it permissions to this site.
4. Now when you go back to your main site, you can use this new group as the target audience for a Web Part.

The issue here is that if you decide later that the permissions further up the Site Collection tree need to be changed, they will not be pushed down because you broke the inheritance.  You can have a site re-inherit from above, but then you lose all your custom permissions; however, the groups that you created stick around.

An alternative approach would be to have all of your groups at the top level and then turn off permissions as you go down the tree.  The difference here is that instead of re-adding permissions after inheriting from the parent you are re-removing permissions.  I would suggest the former because there is less work involved, i.e. fewer groups to play with. 

Either way, this is breaking the inheritance idea a little bit, but it does allow for you to use one permission group to control what is happening on multiple pages.  It allows you to use permission groups up a tree instead of just down it as well.

I’m not quite running with SharePoint yet, but I have definitely improved.  It is quite a powerful tool, if you just know where to look.  At SRT we have multiple customers, and would like to have pages for each of them.  We would like these customers to be able to access the pages that are for them, but we don’t want them to see the pages for our other customers.  Also, all our SRT employees should be able to access all of the links.

Turns out this is pretty easy to do with user groups.

First, in Site Settings->People and Groups you have to set up the groups that you want.  Add the people to each group that you want to be able to see your web part.

Then to get the links on the main page up, add a Summary Link Web Part to your page for each group of links you have:

Next, you need to modify this web part:

This brings up a menu on the right side of the browser.  Open the Advanced tab, and scroll to the bottom:

Here you see that there is a box for “Target Audiences.”  In this box you need to put in the user groups that you want to have access to this web part.  Make sure to semi-colon (;) separate the list of groups, if you comma separate them, SharePoint will not be able to find them unless there is a comma in the group name.  You can then click the “Check Names” button to make sure that the groups you put in are correct.

Now when a user logs in, she will only be able to see the web parts that her group is the audience for.

I haven’t been able to figure out how to propagate these groups to other site collections in a web app, which would be a useful trick.

Also, one quick rant: Firefox does not play well with SharePoint sites.  They are semi-functional, but some of the menus do not work properly even while just viewing the site.  This is not completely surprising, but it would be nice if I could use my browser of choice, rather than being restricted to the behemoth that Microsoft gives to us.

To be overly cliche: you have to crawl before you walk, and walk before you run.  I’m not sure it could be said that I’m walking in the SharePoint world yet, but I have made some steps forward.  Last time I was able to get a simple wiki up and running.  This was crawling, as you can get a very simple page running in SharePoint in a couple of clicks.  For this post, I started by watching a little bit of the next SharePoint episode on dnrTV and found it did not go in the direction that I wanted.  I wanted to go further with my wiki, and they talked about content types that SharePoint could catalog. 

I do need to make a clarification from my last post.  In the second dnrTV SharePoint episode Sahil briefly spoke about web applications and web sites in SharePoint.  Web apps are hosted by SharePoint on a specific port on your server, and they are connected to the content database that SharePoint sets up.  Within each web app is a site collection.  Site collections are, as the name suggests, a collection of web pages.  These pages are stored in a tree structure.  You can create a site collection without creating a web applicatoin, but you do have to attach it to a pre-existing web application.  It is the sites in the site collection that the visitors to your page are served, and the app is place that these pages are served from.

My real purpose for this post was to get an operational wiki.  The first thing that I wanted was to get some pages that could resemble something useful to us.  Next I played with permissions and tried to figure out what they were all about.  Then I played a little bit with the site’s look and feel.  Going on the design philosophy that I should do as much as I can in the browser first, I stuck to the browser for all this.

Making wiki pages works exactly how you would expect.  When you edit a page you are given an area to edit the content of the page.  [[page name|link name]] is used to specify links to other wiki pages.  When you click one of these it will take you to the page, and if it doesn’t exist it brings you to the editor for the page.  Basically, it was really easy to get some content into my wiki.  It is also very easy to put something on the quick launch.  In Site Settings, go to Quick Launch and click Add.  Paste the url of the page in, and voila! you have a new link.  Deleting is a bit hidden though.  To delete (and keep this in mind for other things throughout SharePoint) you have to click the edit icon next to the link.  On this page there is a delete button.

Now I need people to be able to see my content.  SharePoint permissions are pretty easy to understand.  You can assign permissions to people who have accounts on a domain that the server can access.  Permissions are set in Site Settings->People and Groups, and the interface is pretty straight forward.  You put people in groups, and give groups certain rights.  SharePoint has already set up some default groups for you, so if they are good enough you can just add people to these groups.  The problem I faced here was that I had no way to give anonymous users access.  I wanted people to be able to view the site without authenticating.  The answer came from a quick Google search: I found this.  The first set of bullet points seemed unfinished, but the second and third sets gave me the instructions I needed.  After following these instructions I was able to access my wiki without authenticating!  I found that this doesn’t affect search results though, by default you have to be authenticated to access the search results page.  After another quick search I found this.  I have yet to implement it, and will write about it once I do.  It requires diving into the code, which is not something I wanted to do for this post.

The last thing I did was change the look of the blog.  This is quite easy to do in the browser, but the amount of control you have is a bit limited.  In Site Settings there is a Look and Feel heading.  In here I was able to change the theme (background, font color, etc.), add a picture to the top, change the title, and remove some buttons.

I was going to title this post “Stumbling with SharePoint,” but after writing it I feel like I have a pretty good handle on using the browser to edit my pages.

To expand my horizons and to increase the knowledge bank of SRT, I decided to dive into SharePoint and find out what it is all about.  My first step in the SharePoint world was not actually in SharePoint; I first had to setup a virtual machine to run Windows Server on my machine. SharePoint is a server at heart, and so it needs to run on Windows Server, something I was unaware of when I first undertook the task to learn it.  Setting up the virtual machine on my computer was a small adventure in itself. I installed Virtual PC, mostly because we had the disk lying around and I have a license through my MSDN subscription. The first thing I found was that there was no default setup for a Server 2008 virtual machine, so I used the Vista defaults.  After having some performance issues, I would suggest increasing the RAM to 1gig to run Server 2008 well.  The 512MB default seems to be a low target.  Another bit of wisdom would be to name your server something reasonable right away, instead of putting it off until later. Also, it seems pretty important to install the Virtual PC additions on your virtual machine, because they make the experience significantly more enjoyable (a jittery mouse is one of the banes of my existence.)

After getting Server 2008 installed, I immediately installed the SharePoint server.  This was a mistake, as I noted above, because I didn’t change the name of my virtual machine, which left it with a very nasty name that I can’t remember. This is a mistake because the server sets up a few websites when it is installed, with the path as <computer name>:<port number>. Granted, using localhost:<port number> is a work around, but I would still suggest using a usable server name. These can be seen in the Internet Information Services (IIS) manager; you had to install this before SharePoint would install. After installing SharePoint you can open the Administration page (which conveniently is in the start menu, because it doesn’t host on a standard port for each install.)  Looking at this page is a bit daunting, as there is a lot going on.  SharePoint turns out to be a huge package, with a lot of possibilities. Even with this sensory overload of information, it is pretty easy to get a new site up and running.

To create a new site, all you need to do is go to Application Management (the link is on the left side of the screen, under Central Administration.)  In Application Management there is a link for “Create or Extend a web application.”  SharePoint’s websites are all web applications. When you create a new one you a given a lot of configuration that you can play with. The user name for the Application pool, as I understand it, is a user on the server.  On the next page you are able to setup what kind of website you want.  There is a wide array of websites that SharePoint can create for you.  I got a simple wiki up and running in just a few minutes.
Because of the incredible amount of customization that SharePoint browser offers, it is suggested that you start your website development in the browser.  If the browser doesn’t allow you to do something that you need, the next step is to move into the SharePoint Designer.  The Designer is what FrontPage has become.  The last thing you do when making SharePoint pages is dive into the code. All SharePoint pages are stored in one location, and any changes made to them are stored in the SharePoint database. The site’s pages can be accessed from Site Actions->Settings->Master Pages.  I’ll get into editing pages and sites more in later posts.

The shows at dnrTV on SharePoint with Sahil Malik are really good, and held my hand throughout this process.  The first one can be found at: http://www.dnrtv.com/default.aspx?showNum=43.