I am using WSS2.0. Am trying to set some permissions to a document library but not getting the desired behavior. I have created a sharepoint user and assigned it to 'Reader' group. I just want this user to view document library content but not make any changes like check out or upload new document or delete etc. Hence I assign the Reader group. But when I login to the site as this user I am able to delete documents and perform other changes. I checked the document library permissions and it contains Reader, Contributor, Administrator groups and also the permissions are not inherited from the parent.
Is there any other settings I need to check. Have I missed or misunderstood anything?
Please advise.
Thanks,
Jagannath
Based on the details provided it seems likely that the user in question also belongs to another group (local, Active Directory or SharePoint) with the additional permissions.
Related
I need to give permissions to edit/create/destroy pages in a node to a group of users.
I've created a group and added a test user to that group.
I can't seem to give permission to the Pages application so see if i can see the node.
I also added game this role permissions at the node level too.
Ideally this editor role would be able to create new sub pages, which also means being able to upload media.
Your new user must have editor privilege level (you can edit user in Users application). If you want to provide ability to see content in Pages app you have to grant the user with Browse tree and Read permission (content module). To satisfy your scenario you need to grand user with Modify and Create permissions, too (maybe Design?).
Just FYI: The approach provided by Brenden (cloning the role) is very handy but there a is chance you grant the user with permission you don`t want to provide (inappropriate permissions for original role).
I've found the most efficient method is review the out of the box roles provided by Kentico and clone the one which fits closest to your needs. Then modify your cloned role to add/remove abilities and permissions.
If you're unsure of what each role can and cannot do, create a new test user with one of the roles assigned to them and log in as them. Do the same for all the roles you want to test until you find the one closest to what you're looking for.
what the title says. I am not the farm administrator so I guess i don't have access to the sharepoint power shell. I am allowed to use sharepoint designer though and I guess I can set up a webpart that executes code even though I have never done it. I am open to any solution.
Thank you very much.
One way to get all the groups an user belongs to is by checking site permissions of that user
like explained in the article below,
http://office.microsoft.com/en-in/sharepoint-server-help/check-permissions-for-a-person-or-site-HA101794808.aspx#_Toc288817126
Once you enter the user name and check permissions, it will display all the group that user belongs to but you need to be part of the Owner group to enumerate other users' permissions this way.
I want to have user rights split into two. Some of the policies at the client's side mention that we should have a seperate user who has only the rights to add users and nothing else, and the Site Administrator should not be able to add users.
As of now, the Site Admin is used to Add users and to manage other configuration. Can we remove the User Addition role from Site Admin?
Is there a way to create a new User Role by writing some code?
I don't think it is possible to remove any permissions from the site administrator. You could do something wild like add security code to your master page, however. That could detect the current user and the current page, and throw an error if the site administrator were in the wrong place.
You can create a custom permission level, provided your permission sets summarise to one of the options offered by the SPBasePermissions enumeration. Unfortunately there is no specific 'add user' permission, only ManagePermissions. For reference anyway, here's a basic code sample.
I think the best approach is that given by strongopinions where a piece of code runs to check who the user is if they visit the Add User page.
Does anyone know the minimum permissions as user must have to create a document workspace? The problem I have is that I want to users to be able to create document workspaces but to do this I have had to grant the user Create Subsites permission, this however means they can now create other subsites.
Is there a workaround for this?
Unfortunately, if you want a user to be able to create a document workspace, they will also have to have rights to create subsites.
If you're able to remove the need for the user to create document workspaces, then you probably have more options. But this may not be possible for you.
To get around this I simply wrapped the Site Action menu on the master page in a placeholder. Then in the code behind page tested for a permission that I knew the user wouldn't have. This does stop the user from having any access to the Site Action menu but this is fine for my solution.
actionMenuPlaceholder.Visible = (
SPContext.Current.Web.UserIsWebAdmin ||
SPContext.Current.Web.UserIsSiteAdmin ||
SPContext.Current.Web.DoesUserHavePermissions(SPBasePermissions.ManageWeb)
);
I would like to create a folder that users who do not have privileges to view the rest of the site can see. This user group would be granted access to the site, but I only want them to be able to view one particular page.
Is this possible to do without going to every single page and removing the new user group's access?
yeah, you should be able to create a new group and add the users to that list/subweb/whatever and just that. This is assuming that you didn't grant access to all users somewhere. If you did, then hopefully the default access is granted to a default user group (like sharepoint visitors) and you can alter that group to exclude the users you only want to access the limited part of the site.
If created correctly the new group shouldn't have access to the rest of the site.
If you are getting thrown off by the fact that the user/group is listed as having "Limited Access" on the ACLs on, say, the parent site/web. That's just a placeholder SharePoint uses to make sure people have access to at least the bare minimum set of objects (e.g. theme and other UI files and the parent web itself) to get to the list or item you actually want them to have access to.
As long as the group only has access on a single list, you should have to worry about them having access to anything else.