I have used a tool to move over 20 folders into a document library. The tool also moved over the read only rights for the folders.
Now I have 3 users I need to add so that they have contribute access to all of the folders on that library. But when I go to people and groups all I see is stuff for the home page. I only want to give rights to this document library. Do I break inheritance and give individual permissions to everyone listed in the contribute and read only groups?
I am unsure of how to give contribute rights ONLY to 3 people for 1 document library?
You will have to break inheritance for the Document Library and configure the permissions for that Document Library the way you want. These permissions will flow down to all of the folders in the Document Library, unless you break inheritance at the folder level.
You may want to consider creating a SharePoint Group, to which you can add the 3 people, and grant the group Contribute rights to the Document Library. That way if you need to change who can access the Document Library, you can just edit the Group membership. I believe that this is best practice.
Related
Can you please help me on how will I able to filter the items of my list in Sharepoint depending on the user logged. The items that need to be shown will also depend to the team where the user belongs.
Thanks in advance!
So the image below shown is my list.
For example, User 1 and User 2 both have Full Control permission on my list. But User 1 should only see entries for DETE team. And User 2 should only see entries for Service Control Team.
Showing which items to be shown based on the current user can be done using out of the box SharePoint permission features.
The simplest and short answer is to set unique permissions on each item in your list to specific users or groups by breaking permission inheritance for the SharePoint list. Once the inheritance is broken, you can then specify your unique custom permissions on each item in your list. Then SharePoint will only show what is available for the user to see. If you are not familiar with security inheritance in SharePoint, then I suggest reading up on this topic as this is a foundation of SharePoint security.
To do this, use the "Shared With" -> "Advanced" options from the ellipsis menu on that item, then you can break permission inheritance on that item. (If you don't see the tool ribbon, then change the "List Experience" setting to classic via list settings -> advance settings -> list experience)
Then break the permission inheritance on the item:
Then you can grant permission to specific users or groups:
This can work okay for a small list but is a management nightmare for a large list.
One alternative is to use "Folders" and set the appropriate permissions on there instead. Then you can add/remove items from the folder for easier management to control which users can see what. There are pros and cons with this approach but this method has worked for me. What is nice is that you can display the items with or without folders using the Folder display options when creating a custom view.
Another solution is to create a custom workflow that will apply the proper item security permissions for you when an item is created in the list. This is good to automatically set the permissions for you without doing any work but does add maintenance duties if permissions needs changing such as new users, remove users or modifying users.
Setting up the proper security groups and users should give you the flexibility needed for your security requirements. It is always good practice to use groups when possible.
I have a requirement in a Sharepoint 2013 setup wherein I've to give access to external users to a document library. Each User will have a folder by their name, and would be allowed to ACCESS their folder ONLY. They are not even allowed to see each other folder names. They can anytime upload additional or delete the existing documents. External Users are setup using FBA.
Inside the network, there is a Windows user who'll have access to all the folders and documents of that library. I don;t think standard document library can handle this since there is no "Deny View" Permission in Sharepoint.
Sharepoint Folks - Please guide what will be the best way to handle this kind of requirement.
I don't think having a bunch of folders makes sense. However, you could have users upload documents to the shared documents library and have a column in the documents library of the user's username. You could then create a content query on that list to query documents that the current user uploaded. You could then replicate a "folder" type of feel by creating this page, styling it, and directing all users to it.
Let me know what you think of that.
There actually is a way to deny all users. Remove the Authenticated Users, and Remove Anonymous Access from the Library. I agree, that using folders is the wrong idea here. Folders can cause much more harm than help in certain situations.
Create a site to hold multiple libraries, or disinherit the site, remove everyone not essential to the libraries, and use it as a container for the document libraries. Each library can still have it's own unique permissions, and without Authenticated or Anonymous, you'r essentially telling SharePoint that none has access except for the users specified in the ACL's on that library.
You COULD leave the permissions intact on the site and powershell the creation of the document libraries within the site, assigning custom permissions.
I am trying to set up dynamics for a call centre that just wants to do cas management. How do I turn off these things off so there is no evidence of them for a user of the system?
A good place to start would be to edit the SiteMap.
There is a project on codeplex which might be helpful, otherwise you can find good guides dotted around the place:
Editing the SiteMap
Editing the SiteMap 2
With this you could hide Sales & Marketing, which would be a good start. You may also want to look at amending permissions for Leads/Opportunities which can be done by editing security roles. This will help nosey/inquisitive users from creating records if they find links elsewhere.
I presume that you are referring to the subsections of the native CRM navigation structure which shows Workplace, Sales, Marketing, Service and Settings.
Visibility of these areas can be driven in two different ways. You may choose to employ both methods.
Firstly record-type visibility is governed by a user's permissions. Remove a users read access to Invoices for example and it will cease to appear as a navigable option in their UI. Similarly the sub-areas that I previously mentioned will cease to appear if a user has no access to any of the record types that it contains.
consequently it may be possible to achieve some of your aims by giving users the least possible permissions required to do their job (though you should be doing this anyway really) by granting the correct ouot-of-the-box roles or cloning and customising one of those roles. The problem is that the Sales section , for example, contains record types that your users will need to see, e.g. contacts. you won't be able to revoke access to contacts so you'll likely need technique #2 as well:
The CRM sitemap can be customized to contain whatever you want and can even contain new areas. One feature available is to alter or create rules that show/hide areas based on record permissions. I'd recommend downloading the Visual SiteMap Editor and read this part of the CRM SDK
On the "My site" feature of Sharepoint there is a "memberships" Web part that shows the distribution list that the user is a member of.
This is picking up several groups that we would rather not be shown e.g. some that have been set up for administrative purposes only.
Is there any way to control which groups are shown; ideally this would be using another AD group and setting that only members of this group are shown.
I'm fairly sure this won't be possible without a custom web part that is deployed instead of the official part. The reason the Exchange solution doesn't work is because it's going the wrong way (from group to member instead of member to group).
To deploy it you can look at feature stapling... you would need to update the existing sites as well.
This is not an easy answer. I don't believe there is an easy answer.
The best solution would be to set a Deny Access Right for the distribution lists in Active Directory; follow these steps:
1) Open Active Directory Users & Computers as an admin (any user with access to creating groups and modify distribution list security settings).
2) Go to the View menu and make sure that there's a check-box next to Advanced Features.
Create a new security group in Active Directory (call it HideFromSharePoint or something) and add the SharePoint Content Access account (in my case DOMAIN\sa_spcontent) to that group (has to match the account used in step 4).
3) For all of the distribution lists that you don't want to show up in SharePoint do the following:
3a) Open the distribution list and select the Security tab (Advanced Features must be checked for this tab to be shown).
3b) Click on Add and type in the name of the security group that you created in step 3 (HideFromSharePoint); click Check Names and click Ok.
3c) Under Permissions for HideFromSharePoint; check the Deny box next to Read (it's set to Allow by default) and click Ok and Ok again at the prompt.
You've just denied any members of the HideFromSharePoint group read access to the distribution list.
4) Go to SharePoint Central Administration; SharedServices1; User Profiles and Properties; Configure Profile Import and under Specify Account enter the credentials of the account that you added to the HideFromSharePoint-group in step 3. (For some reason if you leave this to using the Default Content Access account SharePoint will use some other account to access Active Directory and thereby being allowed access to the distribution lists. You could experiment with adding other SharePoint service accounts to the HideFromSharePoint group but I think it's safer to specify an account explicitly so that you know which account is accessing AD and importing the data.) Also make sure the "Import Connection" for your Active Directory is set to "Use Default Account" (thereby "inheriting" the account used for Profile Imports).
5) Go to SharePoint Central Administration; SharedServices1; User Profiles and Properties and click on Start full import. (You can't do an incremental import because nothing has changed for the users in terms of group membership; it's just the access rights that have changed.) After completion of the full import (click Refresh until "Import time:" says "Started full import at 11/25/2009 ##:## AM - Ended import at 11/25/2009 ##:## AM")
The distribution lists should now no longer show up under Memberships.
A couple of things to note:
You have to set the Deny Access Right explicitly and individually on all of the distribution lists that you don't want showing up in SharePoint. That's because the special AD-group "Authenticated Users" has read access to every object in the directory by default and explicit Allow Access Rights trump Deny Access Rights set (for example) at the organizational unit level.
While you could skip the step of setting up the HideFromSharePoint-group and set the Deny Access Right directory for the SharePoint Content Access account Active Directory administration best practices is to use a group when configuring security permissions. (Then you can add additional members to that group and have those denied read access too.)
You might have to wait a while (5+ minutes or so) between setting the the Deny Access Rights for the changes to replicate to all of you domain controllers. Otherwise the import might read from a domain controller where the Deny hasn't yet come into effect.
Be careful adding any other accounts to the HideFromSharePoint-group because this might break your distribution lists. For example; if Exchange can't read the groups mail won't work. As long as you just add the SharePoint Content Access Account you're safe.
Also (and this has nothing to do with SharePoint or the solution above) be aware that any user in your domain can fire up ADUC or a LDAP tool and see the members of your distribution lists that way. If you have anything "Top Secret" you need to experiment further with setting access controls in Active Directory.
I assume that your "memberships" web part is using the SharePoint people picker functionality internally.
If that's the case, then the following stsadm command should help you scope your AD lookup the way you want it:
stsadm -o setsiteuseraccountdirectorypath -path <name of OU> -url <URL name>
You could try editing the Distribution List on the Exchange Advanced tab, selecting the "Hide group from Exchange Address lists" check box.
I have not tested this but in theory it would stop the Distribution List from appearing the the list of groups.
Easy fix: add a JavaScript to the page on which those appear that targets and then hides the specific items by applying a CSS style.
I don't have an exact answer, but here's how I would think through the problem. Perhaps you have already answered some of these questions, but it might help to go through them again. I would look at the questions in the following order:
Is there an option in Active Directory to hide a group from SharePoint? (sounds like no)
Is there an option in SharePoint administration (either through stsadm or the actual administration site) to exclude certain users or groups in AD from SharePoint?
Is there a way to configure the web part to exclude certain users or groups from the web part itself?
Is the source code to the web part available such that you can compile the web part to exclude certain groups in the list?
Can you use javascript (as Josh mentioned) in conjunction with the webpart to hide the Distribution Lists from the webpart? (Here's a site with an example of how to use JavaScript to Hide SharePoint's Quick-Launch bar. Maybe that will help).
Those questions are in order from the widest scope and easiest to implement to the narrowest scope that is more difficult to implement. Obviously, you'd like to implement a solution that is easiest to implement, but perhaps you find yourself farther down in the list.
In the last two examples, the solution may appear quite complex, but you may be able to write code that references an XML file of sites to exclude. That way, if your list of Distribution Lists changes, all you have to do is edit the XML file and not edit the source code (of either the javascript or the webpart).
If there's not a simple solution, you'd have to make the painful choice of either 1) letting the problem remain or 2) implementing a hack that adds a dependency to your solution.
I think Distribution Groups that aren't security enabled don't show up in SharePoint. Have you checked AD to see if these groups are security enabled? This may be only for permissions purposes, so I could be wrong.
You will probably need to do a profile import before you see any changes.
You can turn off Distribution Lists entirely, which is what we are doing at my company. This is done by going to the Profile Services Policies in the SSP and disabling the Distribution List feature.
Now if you want to pick and choose the Distribution Lists, it's not that simple, but hopefully this will help someone.
Is there a way to limit the "edit item" permission in WSS 3.0 to only allow a user to edit his own documents or list items? We need the ability for a user to edit only documents/list items he creates - NOT items that someone else created. So, essentially we need a sub-set of the EDIT permission as well as ADD.
Is this possible in Windows Sharepoint Services 3.0? Is there a way to create custom permissions in code or a feature?
WSS has a basic UI for setting item-level permission on list items, but they hide that from the UI for document libraries. If you go into Settings->List Settings->Avanced settings for a list, you'll see the options to do pretty much what you're asking for. However, on document libraries, that UI is not available. The settings it drives, though are avaiable via the object model.
You could set those same properties for a document library like this:
SPDocumentLibrary onlyOwnLib = theWeb.Lists["DocLibName"]
onlyOwnLib.WriteSecurity = 2;
onlyOwnLib.Update();
And that should about do it. However, apparently that doesn't really set permissions; it just controls what the user can do via the UI. If they had another interface to the library (like via WebDAV) or list (like via the web services), it wouldn't prevent them from editing items they didn't create. If you want true item-level permissions, I think you need to go the event handler route.
This post from Matt Morse explains it in more detail, and he even wrote a command line tool to set the property (plus the .ReadSecurity property) for lists and libraries.
If you added an event handler to the document list you should be able to limit edit rights on that item to the user that created the item.
I often have to copy documents from another system into a list in SharePoint, and in that case the edit rights will be assigned to the system user that transfered the document, unless you use the approach suggested by Kirk Liemohn here
Note that item level permissions on large numbers of documents increase the load on your SQL server quite a lot.
here is the solution for your request.
go to the list -> list settings -> Advanced Settings
you will see the section of
Read access: Specify which items users can read
All items
Only their own
Edit access: Specify which items users can edit
All items
Only their own
None
select the options based on requirement. that's it done..
wanna more click on http:// mastermoss.wordpress.com
This is an old question, however the problem still exists.
A way that has worked well for me in the past is to use a workflow to configure the permissions when the library item is added.
See http://www.sharepointusecases.com/index.php/2010/03/configure-item-level-permissions-for-document-libraries-part-2/ for details.
I believe that permissions like that can be created through the user interface. It depends on the scale and number of list items you have, but you could do one of two things. First (without having to create scripts) you could give everyone a custom "Read" permission access which would not allow them to do everything you can in in the Read permission but allow them to Add Items. Then on an item-by-item basis, click the item -> manage permissions -> (Give the specific user Contribute permissions on their document).
If you're creating a SharePoint list that this will not be practical, you can create a script to traverse through all items, and will verify the user has contribute permissions (otherwise it will set the contribute permission to that user).
Additionally, you could just give each person their own folder.
Give everyone read permissions on the SharePoint list/document library, but give each person full control privileges over their own folder. This will allow everyone to read everything in a list, but create/edit their own documents.
If you want the 'Only their own' permission on a document library, it isn't there out of the box. But I've created a solution at CodePlex that adds this for Document Libraries - check it out at http://moresharepoint.codeplex.com.