Michael Ciba

While working on a client site recently I was asked to hide the site actions menu and only allow certain users to view it. After a bit of digging around and searching I found the answer to be the “SPSecurityTrimmedControl” . Now the great thing about this control is that it only renders the contents of the controls it contains if the user has a matching permission level. Therefore the only thing I needed to do was create myself a custom permission level called “DisplaySiteActionsMenu” and assign that to the group or groups who should see the site actions menu. Once this was done all the standard users to the site didn't even know the site actions menu existed. Below is an example of how I updated the master page for the site to make this work. < SharePoint : SPSecurityTrimmedControl ID ="stcHideMasterPageItems" PermissionsString ="DisplaySiteActionsMenu"> < PublishingSiteAction : SiteActionMenu runat ="server"/> </ Shar

Well it’s been a while since I have done a blog entry so I thought I would ease myself back into them with a small post about how to debug a hidden feature. As everyone knows in SharePoint you have the ability to make a feature hidden which means it doesn’t show up via the UI. This is useful if you don’t want users deactivating or activating a feature in the wrong site etc and making a mess of things. However, to debug these features I until quite recently use to switch the “hidden” attribute back to “false” so I could activate the feature via the UI and attached the debugger to the “w3wp” to see what gremlins were making my code go up in a cloud of smoke. However I learnt the other day about the “Debugger.Launch();” method which enables you to launch a debugger for your code and attach to the relevant process to enabling debugging (see http://msdn.microsoft.com/en-us/library/system.diagnostics.debugger.launch.aspx ). Now all I need to do when I want to debug my hidden featu