Mike's Blog

Recently I was asked how we could show and hide things based on user permission, without writing a custom MOSS feature with c# code.  There are a couple ways to do this and rather than me spending type typing up a how to or show examples, I've looked up a couple examples other people have provided on the net:

SPSecurityTrimmedControl - specify what permissions are needed to show the items wrapped in this control.  The blog post below explains this pretty well and shows you all the available permissions you can use.  Notice that at the bottom of the post, the author included a code example.

An example of using this would be to hide the Site Actions menu for everyone who does not have permission to AddAndCustomizePages and ManageLists... in other words, do not show the site actions menu for users who are visitors or contributors.

Referenced blog post - http://zac.provoke.co.nz/archive/2007/05/31/spsecuritytrimmedcontrol-possible-values-for-permissionsstring.aspx

MenuItem PermissionsString - specify what permissions are needed to show the current menu item.  The blog post below documents this pretty well and shows a very good example for hiding 'edit page' from the site actions menu using this method.

Referenced Blog Post - http://www.sharepointblogs.com/holliday/archive/2008/01/14/hide-edit-page-in-site-actions-menu.aspx

I stumbled across this article on accident this morning and thought I'd share it... for those who are new to SharePoint or need some clarification on authentication, user groups, user profiles, etc in MOSS 2007, check out this article on Bamboo's website... its quite well done and really helps make things much more black and white if you're unfamiliar with it.

http://store.bamboosolutions.com/kb/article.aspx?id=10829

For those of you interested in who the top bloggers are out there, check out this list

Top 100 SharePoint Blogs of Spring 2008 - SharePoint Joel's SharePoint Land

Anyone else out there get annoyed with the "Attach Security Warning" dialog?  It gets pretty annoying when you attach to multiple processes (ie: w3wp.exe) and have to click 'attach' for each process every time you debug... anyhow, solution is below...

Find the following registry keys:

• Visual Studio 2008 - HKEY_CURRENT_USER\Software\Microsoft\VisualStudio\9.0\Debugger\DisableAttachSecurityWarning
• Visual Studio 2005 - HKEY_CURRENT_USER\Software\Microsoft\VisualStudio\8.0\Debugger\DisableAttachSecurityWarning

Change the value from 0 to 1.

A recent project I'm working on requires some data to be stored in SQL (for reporting purposes) but be manageable through SharePoint without creating custom edit/display forms since the data was used on several custom screens that we were already developing.  The logical step for this at the time seemed to be to use SharePoint Lists, then import/export them into a SQL database using SSIS... there are other ways to do this besides SSIS, but this seemed to be the quickest and easiest rather than creating custom workflows, event handlers, or edit screens.

While this sounds easy since SSIS can consume web services, it turned out to be a little more complicated since SSIS cannot consume certain SharePoint web services, specifically the Lists service.

Long story short, I was able to get a demo going that actually met all the requirements... I've posted some links below to explain how to do the whole thing but also provided a general outline on what it takes to get it done.

1. Create a proxy class for your web service - this is actually very easy..
   1. create a new class library
   2. add the web reference to your web service
   3. sign the assembly
   4. build and copy the dll to the .NET framework 2.0 folder
   5. install in the GAC.
2. Create a new SSIS package
   1. Add a script component to the control flow
   2. This script needs to reference your proxy class
   3. write the code to read from the lists which returns xml objects
   4. apply some XSLT to clean up the xml
      1. specifically need to fix the namespaces, SSIS apparently cannot read XML with multiple namespaces
   5. Add a dataflow task to save to the DB
3. Add any additional logic/controls to the SSIS package
4. Run it
5. If successful, check your destination table/db

While it sounds like a lot of steps, you only have to do the first step (proxy class) once for each web service... then you can reference it in each SSIS package and specify the list to query.  The annoying thing is using the script component to query the lists and get it into a variable, but it didn't take much to do that and you can copy/paste for each use... the only change you'll have to make to the script is the variable name to store the results in and the list name to query.

References:

• Exporting Data from SharePoint 2007 lists to SQL Server via SSIS
• Sync your database to SharePoint using SSIS
• Calling SharePoint web services from the data flow