SharePoint Duffbert

In our environment, we have a small number of custom web parts that work with our company intranet.  Let’s call them “Current News – Left” and “Current News – Right”.  They take information from the “Current News” list and show them in two different columns on the page.  All in all, it works.

The problem is that some people see the Left and Right web parts and think they want to have the same layout on their page.  They put the page into Edit mode, add the web part, and BOOM!  Their page now throws a generic error and they have no idea how to get back into the page, much less what to do to fix it.

The problem is that the way these two web parts were coded, they require that the “Current News” list already exist.  If the list exists but has no items, that’s fine.  The Left and Right web parts are empty.  But if the list doesn’t exist at all, the page blows up.

In order to get the page into a mode where I can delete the web part(s), I go to the URL of their page and add “?contents=1” at the end.  That gives me the Web Part Page Maintenance screen for that page, and I can close, reset, or delete the web parts from that interface.

Once I remove the “Current News” web part(s), the page works again.  The other way I could fix it is to add the “Current News” list, but knowing about the “?contents=1” trick gives me a lot more control, and can be used in various situations.

This was a strange issue that fortunately has a technote for it…

We had a person who used to be a contractor and then subsequently became an employee in a different area.  They were added to a particular site with Contribute level access, but whenever they tried to get to the site, they’d get an access denied message.  In Active Directory, they had the correct information for their new position.  Their My Site had all the right profile information.  But when I’d use the People and Groups dialog box to add them to the site, they’d show up with the contractor information.  It was as if the person in that site was different than the person we were trying to add.

After some searching (and flailing for the right combination of keywords), I found a technote from Microsoft that explained the issue:

A user’s display name is incorrect on a specific SharePoint Site Collection

A user in your organization has recently updated some of his or her information (such as the user’s display name) in Active Directory Domain Services. The information was updated correctly in the user Profile Service Application. However, on a specific Microsoft SharePoint 2010 Site Collection, that information was not updated.

The key is to remove them from the All People group in the Site Collection, which can be found in SharePoint 2010 at <Site URL>/_layouts/people.aspx?MembershipGroupId=0.

Once I did that and then re-added them, their information was correct, and they could access the site with no issues.  Whew!

I got a help desk case today asking if I could tell who had updated permissions on a particular site.  After a little bit of Googling, I was able to get the basic information for them.  Go to the site in question and do the following:

• Go to Site Actions > Site Settings > Site Collection Administration > Site Collection Audit Settings
• Check to see what’s being audited.  In my case, I was fortunate in that the List, Libraries, and Sites > Editing Users and Permissions was selected (which is what I want).  If that hadn’t been selected, I could have only set it and audited items going forward from this point in time.
• Click OK

Now to run the audit report:

• Go to Site Actions > Site Settings > Site Collection Administration > Audit Log Reports
• Click the link for Security Settings under Security And Site Settings Reports
• Select a location where the spreadsheet report will be stored.  In my case, I just used the Shared Document library.
• Click OK.

The report will churn away for a short bit and save the spreadsheet when its done.  When you go into the location where it’s saved, just click on the file and Excel will launch.

There are two sheets in the report.  The first is summary information (which wasn’t of much use to me), and the second sheet is the detail.  You’ll quickly see that the information will never be mistaken for “user-friendly”, but you can dig through and find who added, deleted, or updated permissions to the site.  It doesn’t tell you what was added or changed, but at least it gives you a general guide to who has been making updates and when they occurred.

Once I learn more about SharePoint, perhaps the other columns will be of more use to me.  But for right now, this worked for what I needed.

This is one of those tips that was shown to me by Sandra (who will be known and referenced in all subsequent blog entries as SPB – SharePoint Buddy), but I kept forgetting how to do it every time I needed to remember it.  Let’s fix that right now…

When you create a workflow for a list and set the trigger to run it manually, you normally have to click the dropdown next to the list item, then select Workflows, then find the right workflow, then…  you get the idea.

You can take a few steps out of that process by putting the workflow directly on the list item menu… Go into SharePoint Designer (I’m using SPD 2010) and navigate to the list that contains the workflow:

The resulting dialog box will give you the options for what to name the list item menu entry, and what it should bind to:

I go back to the site and try the list item menu again, and voila!

Thank you, SPB…