views:

785

answers:

6

I have users in the Site Owners group of a root site, trying to copy (or move) pages between Pages Libraries in two subwebs. The permissions of the subwebs are inherited from the parent, with no changes, so the Site Owners of the root are the Site Owners of the subwebs as well.

When a member of the owners group tries to move or copy a page, it fails. 12-Hive logs show an Access Denied error being thrown.

Is there any way to allow this to happen without giving these users Site Collection Admin access?

EDIT: This is via the Manage Site Content link in the Site Actions, on a Publishing Site. Copy/Paste or drag/drop between two explorer windows works correctly.

A: 

Maybe you could try explicitly giving permissions on the sub-sites to the desired users.

Did you mean by copy/move using the "Explorer View"?

emirc
A: 

This isn't really a permissions issue. SharePoint doesn't really provide a mechanism for moving content between libraries / sites.

If you're running Windows I'd suggest using 'view in explorer' under the tools menu for both libraries and drag the files between the two windows. This should be available to contributors on the site*.

  • unless someone has mucked with the definition of 'contributor'..
Kevin Davis
Sure it does - under the Manage Site Content link in the Site Actions, on a Publishing Site.
Greg Hurlman
Also file copy operations don't move Web Parts
Peter Seale
+1  A: 

We had this problem on a couple of our sites as well. It turned out to be an issue with the page layouts associated with the content pages we were trying to move. Strangely enough, if the associated page layout had any draft versions in its version history then the move operation would fail with an access denied error. As soon as we deleted all draft versions on the page layout, the move operation would succeed.

I'm still not entirely sure why this worked - I'm hoping to find some time in the near future to do a little more investigation.

edwach
A: 

The Manage Site Content page is based off of the PRIME API which is ~buggy. Try to find out what your users are trying to do (i.e. find out why they're moving pages) and give them a workaround (e.g. ask them to create new content pages and paste the data; show them how content approval works so they feel comfortable working on the production site; use a formal Content Deployment process.)

Depending on what your users are trying to do, most/all of my specific suggested workarounds are going to be way off base.

Peter Seale
A: 

Whilst I've not experienced this problem personally, The hidden list 'Long Running Operation Status' located at http://[yourdomain]/Long%20Running%20Operation%20Status/AllItems.aspx is written to multiple times during a copy / move or delete operation via the Manage Site Content (aka Site Manager) tool.

It might be worth checking that your problem users have write access to this list, or explicitly assign contribution access and see if this fixes your problem.

References:

Edward Wilde
A: 

I basically overlaid the permission policy with the same rights from the command line.

This is the command I used: stsadm -o addpermissionpolicy -url -userlogin -permissionlevel <"Full Control">

The key is the double quotes on the –permissionlevel parameter. After I did this the user could move/copy pages w/o being a site collection administrator.

related questions