Sue Hernandez's SharePoint Blog

SharePoint and Related Stuff

Category Archives: Best Practices

SharePoint Designer 2010: You do not have permission to do this operation

SharePoint Designer 2010:  You do not have permission to do this operation
–  or  –
Master Page Error:  The Master Page File ‘https://yourserver.com/yourPath/yourSC/_catalogs/masterpage/v4.master‘ cannot be loaded.  Attach a different Master Page, or correct the problem in Code view.

Environment Specifications: 

  • SharePoint Designer 2010. 
  • Windows XP OR Windows 7
  • All of the problem sites were sites that had been migrated from 2007
  • All of the users having problems had FULL CONTROL of the sites they were trying to get into
  • When using a VPN, we always get both errors
  • When outside of the network completely (our site is accessible on the internet with credentials) then we sometimes do not get the first error, but we can’t put the page into Design mode because of the second error.

So we figured out that it had something to do with permissions at the Master Page Gallery at the top of the site collection.  But what was wierd was that any new subsite we created did NOT have this problem.

Well, to make a long story short, we were right, and it’s a “feature”.  KB Article http://support.microsoft.com/kb/2592376 from Mirosoft explains that you have to be one of 3 different permissions, at the site collection level, in order to edit in designer:

  • Site Collection Administrator
  • Designer
  • Owner

Now we whittled it down to this – you don’t have to be in the “Designers” group at the top of the site collection – but if your configuration of the Master Pages Gallery was untouched, that WOULD work (because Designers were set as Design level in the Master Pages Gallery).  Basically the short of it is, you need to HAVE DESIGN OR GREATER PERMISSIONS ON THE MASTER PAGE BEING USED (or just the whole gallery) at the TOP OF THE SITE COLLECTION.

Turns out the reason for these varying behaviors is this:  In 2007, new sites would automatically inherit their master pages from their parents.  If you made no changes to that, it inherited right up to the top.  So it’s looking at the master page from the top, in those circumstances.  And as we’ve seen here, if you don’t have Design permissions to it, it doesn’t work.

In the case of a new 2010 site (just a regular Team Site), the new 2010 behavior is to use the Master Page in the gallery it has in its own site.  And since the user is an Administrator (Full Control) of that site, then no problem getting to the Master Page!

Just so you know, we did end up calling in a Microsoft Ticket on this one, to confirm our findings.  We knew at that point it had to be something about permissions at the top, but we didn’t know why.  They confirmed it, providing the KB article I mentioned earler, and the explanation you see in this article.

SPListItem.DoesUserHavePermissions doesn’t work…or does it?

Don’t you hate when you make dumb – and upon later inspection, rather obvious – mistakes?

I was struggling (I’m too embarrassed to tell you how many hours) with the fact that even though I had broken permission inheritance, my code was always saying that the Current User had access to the list item – and full access at that (that should have been my first clue).

bool hasPermissions = false;
try
{
       //http://blogs.msdn.com/b/ryanrogers/archive/2004/07/15/184594.aspx
       site.CatchAccessDeniedException = false;

       hasPermissions = item.DoesUserHavePermissions(SPBasePermissions.ViewListItems);
}
catch (Exception ex2)
{
       hasPermissions = false;
}
finally
{
       site.CatchAccessDeniedException = true;
}

if (!hasPermissions)
{
       ShowError("User does not have permissions to list item");
       return;
}

So I thought the above code would work.  From everything I could see on the web, it SHOULD have worked.  So why didn’t it?

Turns out that I was running in Elevated Privileges mode, so the “Current User” was the system account.  Now mind you, that code above was NOT inside that Elevated Privileges wrapper – that’s what threw me I think.  But, what I did do (and I’m questioning now WHY did I do it this way) is that I had an SPWeb object variable that I set inside the RunWithElevatedPrivillges method.

SPList list = null;
SPWeb web = null;
SPSite site = null;
try
{
       SPSecurity.RunWithElevatedPrivileges(delegate()
       {
              using (SPSite secureSite = new SPSite(webURL))
              {
                     site = secureSite;
                     using (SPWeb secureWeb = secureSite.OpenWeb())
                     {
                           web = secureWeb;
                     }
              }
       });
}
catch
{
       ShowError("Could not retrieve web at '" + webURL + "'");
       return;
}

try
{
       list = web.Lists[listID];
}
catch
{
       ShowError("List ID '" + strListID + "' not found in web");
       return;
}

try
{
       SPListItem item = list.GetItemById(itemID);

So apparently the web object stayed elevated, thus the list was elevated, thus the List Item was elevated.  All I had to do was use the overload of the DoesUserHavePermissions method.  But that being said, I’m rethinking this whole, “pull it out of the elevated wrapper” thing I have going on here.  I’m marking this post as “Best Practices” as in what NOT to do :-).

hasPermissions = item.DoesUserHavePermissions(SPContext.Current.Web.CurrentUser, SPBasePermissions.ViewListItems);

Basic InfoPath Tips and Tricks

I just had a great seminar yesterday on InfoPath and I thought I’d share some of the tips and tricks that we discussed, as well as a few that we did not.

In general, these are the steps you should take, in this order, to prepare a form for use in SharePoint:

  1. Create the InfoPath Forms Library on your site.
    You will need this URL when creating connections such as a Submit connection.
  2. Create the new .xsn file (InfoPath Form).
    I recommend using a blank template when working with InfoPath 2007 – gives you much more flexibility.
  3. Create the Data Source for your form.
    Do this BEFORE you start to design your form – it will make your designing go more smoothly.  Create a wireframe mockup, for instance an indented bulleted list.  Use Groups liberally to act as containers for related sets of information.
  4. Lay out the general Design of the form.
    See below for a tip on my idea of form design.
  5. Add Buttons and other periferal controls to the form.
    For example a button to Save and Close the form
  6. Apply Formatting, Conditional Formatting, Totalling, Rules, Formulas.
    Use formulas and Default Values to come up with calculated fields. 
  7. Create Alternate Views.
    After you create one full form view, you can either copy that view and make modifications, or, in a Wizard-like form setup, you can continue on with the rest of your questions (see below on the tip for the Form Wizard).
  8. Create a Print View.
    You can create a view that is specifically for a report.  Make it a Read Only view, and place whatever other text or disclaimers
  9. Publish your Form to SharePoint
    Use the Publish feature in SharePoint 2007, or the Quick Publish feature in 2010 (you can’t use Quick Publish till you’ve published regularly once first).  Promote any columns you wish to use, and see below for a tip on field promotion.
  10. Configure the Forms Library to display as a web page.
    Go into Form Library Settings –> Advanced Settings and click the radio button “Display as Web Page”.
  11. Test your form using both priviledged and non priviledged accounts.
    Especially if your form contains logic or conditional formatting to only display certain controls to certain people.

Here are some basic Tips and Tricks I’ve come up with:

  • You do NOT need 2 SharePoint Libraries for your InfoPath forms – you only need one library which both holds the template (in the background) and holds the completed forms in the list.  Make sure you Publish to a Form Library and don’t just upload it.
    • That being said, you can always have a second library called “Form Templates” as a place to centrally store your design templates, but this is not where your users go to fill them out.
  • If you lose your Design Tasks pane, find it in the View menu in InfoPath 2007.  In InfoPath 2010, use the ribbon’s Data tab and select Show Fields to see your data source.
  • In InfoPath 2007, when you want to have a rule that runs when the form is opened, you go to Tools –> Form Options –> Open and Save –> Rules (button) [for instance to set a user name field when they first open the form].  In InfoPath 2010, you go to the ribbon’s Data tab and press the Form Load button – this brings up the Manage Rules pane, but in the context of the form opening.
  • Groups, Groups, and more Groups – when creating your Data Source I recommend using Groups (they look like folders in the Data Source Pane) to categorize your fields into logical sections.  You can use groups within groups as well, if it makes logical sense to do so.
  • Use a Submit Button that you create, with a calculated file name, to both submit and close your form.  That way the users will not have to come up with a file name or get confused on which toolbar buttons to press.  You can create a data field called fileName and populate it on form load – only under the condition that it hasn’t already been filled in – to the “concat” of the user name of the originator plus the “now” date time function.
    • If you choose to go this route, go to Tools –> Form Options –> Browser (InfoPath 2007) or File –> Advanced form options –> Web Browser (InfoPath 2010) and remove the options for Save, Save As, and even Views (also control those with buttons)
  • When wireframing your data source, don’t forget to properly represent any table-like sections – implemented as “repeating sections” in InfoPath.  For example, if you have expenses for one day, the expenses should be a “repeating group” to capture all of the columns for each row – each expense and its metadata.
  • Always rename the top node of the Data Source.  Don’t leave the default of myFields.  Rename it to what makes sense to that particular project.
  • Use the correct casing in names of fields (I think it’s called Title Case) to make the design of the form easier.  For example, if you create a field named EmployeeName (notice the E and the N are both capital), then when you drag the field on to the design surface, it knows to put “Employee Name” there for you (it inserts the space).
  • You can’t re-use field names anywhere in the Data Source – even if they’re in different “Nodes” or groups.  So if you need to, use a prefix, like TravelExpenditures and OtherExpenditures.
  • When designing your form – use a big ol’ layout table in the design surface.  Choose between 15 and 20 columns wide and about 30 rows long.  This is to line things up properly – you won’t have to play around with widths and spacing and you shouldn’t have to adjust the sizes of the columns.
    • When creating places for your data controls to go, merge together some cells, depending on where you want to place the controls, and then drag your controls into the merged area.  Either keep the default of the text on top, or merge cells to the left to hold the title.
    • Using tables in this manner is very helpful – you will note that when you use a table and drag in a control, the control automatically “fills” the width of the section you drag it in to, making things line up just nicely.
  • If you have a lot of conditional logic/branching (i.e. the questions they need to answer depend on the choices of questions above them), then you can set up a Wizard-like form using views and buttons.  Each View should be a “page” of questions that go together.  Then you create a button at the bottom of the view, right after one of the questions that needs conditional logic.  The button will have one or more rules – for example [If the IsOver500 equals True Then switch to the “Over 500 View”] and [If the IsOver500 equals False Then switch to the “500 and Under View”].
    • Don’t forget to add appropriate “Previous” buttons to make sure that the users can get back to the questions they have already answered.
  • If you have a need to make a lot of fields read-only, you have the option of creating a view with only those fields and making the entire View read-only instead of setting the Read Only property of every control.  This works well for Report or Print views.
  • When you promote fields during publish, be very aware of the choices in the dialog box.  You need to choose whether or not the columns should be Created in the library, whether you use Existing columns in the library, or, in cases of content types, if you want to use existing or new Site Columns.

Some References for you: