We've started to adopt SharePoint 2010, and are starting to manually migrate content from SharePoint 2007 sites to new sites we're rebuilding from scratch in SP2010.
One of the things we previously had supported was to delegate responsibility for managing some of our site columns to a member of the team. The team member is not familiar with SharePoint internals, and doesn't want the responsibility of full permissions to the site and all its objects.
We're now trying to figure out what the minimum permission is that we need to grant our team member, so they can continue to edit (& propagate) the content of the site columns we've defined.
Permissions he currently has (which are obviously insufficient):
Site permissions (according to _layouts/user.aspx): Read, Contribute, Manage Lists
Permissions for specific objects in the site (according to _layouts/people.aspxMembershipGroupId=xxx, then choosing Settings, View Group Permissions):
server/sites/[sitename]: Contribute
server/sites/[sitename]/Lists/[a list with columns that inherit from site columns]: "Contribute No Delete"
Note: the "Contribute No Delete" permission is a custom permission I designed by copying the SharePoint-native "Contribute" permission set and deselecting the Delete permission. The "Manage Lists" permission is a custom permission I designed that includes the following specific permissions: (List Permissions) Manage Lists, View Items; (Site Permissions) View Pages, Open.
Operations that are throwing access denied errors:
_layouts/mngfield.aspx: SharePoint returns the "Error: Access Denied" dialog, and provides three clickable options: "Sign in as a different user", "Request access", and "Go back to site"
_layouts/fldedit.aspx?field=Level%5Fx0020%5F3 [one of the site columns we've defined]: can load the page and type in changes to the textboxes "...but when I press OK (save changes) I get the same message above."
When our team member clicks the "Request access" link, the email I receive sends me to a page that recommends that I grant the user membership in the "[sitename] Users" group - of which he's already a member. So while SP2010 tries to request access, it doesn't actually direct me to either (a) a valid group that has the correct permissions or (b) the specific object to which I need to grant our team member access.
Also note: on the SP2007 (MOSS) site (where our team member was successful in managing Site Column edits), they had dozens of additional permissions throughout the site that we do not wish to blindly re-allocate in SP2010 until we know they're necessary.
Any help anyone can provide would be greatly appreciated.
There are two sets of permissions: one set of permissions that are set at the Site level, and another set of permissions that must be assigned on every List where the Site Column is being inherited (i.e. where it's been implemented as a List column):
Site-level Permissions
Manage Lists (labelled “List Permissions”)
View Items (labelled “List Permissions”)
Add and Customize Pages (labelled “Site Permissions”)
Browse Directories (labelled “Site Permissions”)
View Pages (labelled “Site Permissions”)
Open (labelled “Site Permissions”)
List-level Permissions
Manage Lists (individual permission – which includes View Items, View Pages and Open)
Contribute (permission set)
For details and the methodology on how I arrived at these permissions, you're welcome to rad the whole gory story here: http://paranoidmike.blogspot.com/2010/10/found-minimum-permissions-to-edit-site.html
Related
I have a dev Sharepoint site with unique permissions (and fake users seen below). In the SharePoint manage access blade, the permissions appear as such:
However, when I click through to the Advanced Permissions link just below that, the permissions look as such:
MaksSite Owners is missing in the 2nd listing, though it appears in the first listing. This group appears to be the default Owners group that came with the SharePoint site. It is also missing when queried through the SharePoint REST API (via /sites/MaksSite/_api/web/GetFileByServerRelativeUrl('/sites/MaksSite/path/to/file')/ListItemAllFields/RoleAssignments?$expand=member). Which listing is right, and if it is the first listing, how do I get it to appear, at least with the API?
By default, the Site Owners group is hidden in the list. To make it appear, please take the following steps:
Click List Settings under Settings.
Scroll down to Views, click Detail View.
In Filter section, choose show all items in this view. Then save the view.
The Site Onwers group will appear in the list:
You could try to use the below Rest API:
/_api/web/GetFileByServerRelativeUrl('/sites/michael/Shared%20Documents/Document.docx')/ListItemAllFields/RoleAssignments/groups?$expand=users
I have a SharePoint Site where I created a List and I want to give read and add access to this list only to a limited group of people.
First I created in the SP site the List "ListX"
In the ListX settings I went to list permissions and I stopped inheriting permissions from the site and I created unique permissions
On the site advanced permission settings I created a new permission level "Add and View Only" where I selected the following options:
On the list permissions section
(a) Add Items - Add items to lists and add documents to document libraries
(b) View Items - View items in lists and documents in document libraries
The moment I selected those two options the following options have been automatically selected for me on the site permissions section:
(a) View Pages - View pages in a Web site
(b) Open - Allows users to open a Web site, list, or folder in order to access items inside that container
Then on the site permission I created a SharePoint group "ListX Users" and I gave the permission level "Add and View Only"
Then I added several users in the SP group "ListX Users"
Then I granted permissions on the ListX permissions to the "ListX Users" SP group
However the user gets the message "Sorry you don't have access" when they try to go to the top level of the site so that they can click on the ListX link and they are prompted to request access.
Any idea why that happens and how to give such Add and View access to the ListX only? Thanks
Best (and easiest) imo is to work down. Give them permissions on site level and break inheritance on each library that shouldn't be visible for everyone.
That way the navigation is the easiest and for maintenance has the easiest overview.
I partially solved my issue by adding two more options in the List permissions permission levels of "Add and View Only". See below.
Open Items - View the source of documents with server-side file handlers
View Application Pages - View forms, views, and application pages. Enumerate lists
However in this case the user need to have a direct link to the list and cannot navigate via the site.
I have a sub-site (http://mysite/documentcenter). My user is in Site Collection Administrators, so I can see and click the move button in site content and structure of sub-site.
But the other users, who has contribute access to all documents, can't see the Move button - it completely disappeared, it's not greyed out.
How can I make the move button display for the other users?
I know this question is a bit old but, you need to have the following Permission Level enabled or Move is not available.
Manage Web Site - Grants the ability to perform all administration tasks for the Web site as well as manage content.
I would be very careful assigning this permission though as it adds a whole slew of additional access for the user(s).
Make sure Add and Customize Pages permissions is present. There could be a Deny mask coming in from User Policy from central admin, which can overwrite Site Collection admin permissions.
My team implemented a UI to assign/revoke permission levels to users on a certain SharePoint list. The UI supplies an "undo" feature to restore the rights the user had before they were changed through our UI.
Now there is a problem if the user had the "Limited Access" permission level: This permission level is removed when you do a change over the UI. When trying to Undo, the permission level should be added again, which leads to a
You cannot grant a user the limited access permission level.
SharePoint grants that permission level automatically when a user gets access to some entity beneath the site. It cannot be granted manually. This permission level is then inherited by all lists in the site. However, after breaking inheritance on a list, I can revoke the right manually, only, I cannot re-grant it afterwards.
So SharePoint treats that permission level quite particularly and I'm wondering how to work around that in our undo feature.
My questions:
Did I get it right that this "limited access" is granted by SharePoint on the site level only, and all the lists beneath only contain that accidentally through inheritance?
Does that permission level have any effect at all on a list, or does it only apply to the site itself?
So, would it be save to just remove it from a list and do not add it anymore when the user clicks "undo", since it has no effect anyway?
I dare to answer my own question just for reference for future readers:
According to Microsoft's article Permission levels and permissions,
The Limited Access permission level
cannot be customized or deleted.
and
(...) Windows SharePoint Services 3.0
automatically assigns this permission
level to users and SharePoint groups
when you grant them access to an
object on your site that requires that
they have access to a higher level
object on which they do not have
permissions. For example, if you grant
users access to an item in a list and
they do not have access to the list
itself, Windows SharePoint Services
3.0 automatically grants them Limited Access on the list, and also the site,
if needed.
In practice this means that:
If you can delete it, that's only because it has been inherited and has no meaning on that certain list.
If later on a user is granted some permissions to a certain list item, so that he needs the Limited Access on the list, SharePoint will take care of adding it again.
Summarized: No concerns to remove and not re-add that access level.
Removing a user with Limited access on the top level site should not actually remove their explicit access on the list or library below (with broken permissions) but MS do say in the above mentioned article:
However, to access a list or library, for example, a user must have permission to open the parent Web site and read shared data such as the theme and navigation bars of the Web site. The Limited Access permission level cannot be customized or deleted.
This suggests that the user's Limited access should be declared on the site permissions. I think its always best to do a test on your site first before making any assumptions.
Let's say I have 2 AD security groups: "Access to SharePoint" and "Access to Archive".
How do I set the security in this way on a SPWeb that only people who are member of both groups, are allowed access?
Is this possible with out of the box AD tools?
Thanks!
I am making the assumption that you are using SharePoint 2007. With that being said, its best practice to only apply security at the site collection level. Everything under the site collection level should inherit that security [e.g. sites, lists, libraries, items, documents].
EDIT:
*#OedipusPrime brought up a good point that I overlooked in my original answer. The best thing I can think of now to ensure a SharePoint group only allows users that are comprised of two different Active Directory groups would require a custom script that would need to be run on a regular basis (at least daily I would assume).
You'd still create a new Active Directory group, but you'd populate the group with a C# console application that would query Active Directory and determine which users were in both Active Directory groups ("Access to SharePoint" & "Access to Archive"), then programmaticlly assign those users into the new Active Directory group ("Restricted Site Access") and remove any users that were no longer in both groups. Not the best option, but the best I can think of for now if you're not able to manually control the Active Directory group access. This link provides some useful samples for C# / Active Directory interactions: http://www.codeproject.com/KB/system/everythingInAD.aspx*
After this new Active Directory group is created you can add the group to your SharePoint site and provide the permission level the group will have to the site.
Site Actions -> Site Settings -> Advanced Permissions -> New -> Add Users
Type in the Active Directory group you created
Select Give users permission directly
Choose the permission level
Uncheck the box to send an email
Click OK