In some cases, your site may contain content only meant for certain users or groups. For example, you may create a new library for a special project, and want to ensure that only people who work on that project can access the library.
Access can be granted or restricted. To restrict access, you have to break permissions inheritance, and then change the permissions for the list or library on a uniquely defined permissions page. Read below to learn more.
To restrict access to a list, remove the users or groups from the group that has permission to access the list. To remove users from a group, follow these steps.
The permissions page updates to show that the group or user no longer has permissions to the list.
Note: Make sure to leave Visitors as “Read Only.”
The best way to control permissions within you site is to create permission groups. Without a permission group, you will have to change all of the affected users, when you change permissions. The following provides the steps involved in creating a permission group.
Anonymous access means that people without an APAN account will be able to see your APAN SharePoint site.
While using standard SharePoint, if a site owner allows access requests, an unauthorized user fills in a single box to request access. A notification email is sent to the site owner, with the contents of the text box. When the site owner clicks on the Approve link in the email, the requester is given access to the group, but is not added to any permission group. The decision by the site owner to grant access is limited to the brief, if any message that the requester provides.
The APAN Pending Members feature improves the request process for the site owner and the requester.
The APAN Pending Members feature uses a SharePoint list named Pending Members. When an unauthorized user requests access, the request form contains all of the customized items, added by the site owner. Additionally, site owners can easily add approved user to particular permission groups.
The APAN Pending Members feature must be activated by a user (usually the site owner) with Full Control of the site. This feature is activated by the following steps:
Activation of the Pending Members features creates special permissions for this list. Because you want APAN users to complete a request form, NT AUTHORITY\authenticated users group has Pending Members permission to write to the list. They cannot edit or read the list items. Turing on the feature gives Full Control of the list to your site’s Owners group.
As of May 2015, Pending Members feature requires that there be an Owners group and a Members group at the site level with a name that matches the site name. For example, if your site name is Exercise EF 2015, you must have Exercise EF 2015 Owners and Exercise EF 2015 Members at the site level. If you change the name of the site or the name of your owners group, Pending Members will not function!
When the feature is activated, unauthorized users will be prompted to complete a request form, as usual. Site owners are encouraged to use the Pending Members feature to improve the evaluation process for granting access to their site. Site owners can customize their request forms by adding columns to the Pending Members list.
A customized Pending Members list opens the possibility of creating a roster list, database, or a list of attendees to a conference. If you are requesting information that you don’t want to share with all members of your group, it is suggested that you export the list, using the Approved view to an Excel spreadsheet. Delete the columns that you don’t want people have, such as flight information, and import the spreadsheet as a new list in your site.
You can add as many columns to the Pending Members list as you need. You can change the list whenever you want. You can make items mandatory or optional.
By default, all sites, lists, and libraries in a site collection inherit permissions settings from whatever is directly above them in the site hierarchy. This means a site inherits permissions from the root site of the site collection, and a sub-site inherits permissions from its parent site. A list inherits permissions from the site that contains the list. A list item inherits permissions from the list to which it belongs.
If the default configuration is not changed, permissions are inherited through the whole site collection. In a way, each element (site, sub-site, list, library, etc.) inherits permissions from the root site of the site collection.
If you break permissions inheritance for a list or library and then define new permission settings, the list (or library) becomes a parent for items in it. The items inherit the new permission settings (unless the items have uniquely defined permissions.
When you break permissions inheritance between a site, folder, list, library, list item or document and its parent you can restore inheritance at any time.