@April: "Anyone experience an issue when groups mysteriously 'disappear' from a single 
site. We have one site with multiple lists/libraries that each have unique 
permissions. The same groups were deleted from the site and all 
lists/libraries within, but they were never set to re-inherit the 
permissions. 
Is it possible to delete a group from the site and all lists/libraries 
within that site even if they each have unique permissions?"
    @AdamClark: "Hi April,
  in general lists and libraries cannot delete themselves without user 
actions being defined (directly or via workflow).  In your message you 
mention a point around permissions and inheritence/de-inheritence of 
permissions.  have you had your Site Collection Administrator check the 
permissions for the list or library (as this is the one role that cannot be 
denied access to content).  Rememebr that if a person is not in the security 
for a list then they will not see the list which may be the cause of your 
problem.
Hope this helps.
Adam Clark
<quote>"
    @April: "This issue was not in content/sites being deleted, but in people and groups 
being deleted from a site and un-inherited libraries. 
I figured out the issue:
Regardless if a list or library is no longer inheriting permissions from the 
site, if you delete that user or group from the Site Permissions page, they 
WILL be deleted from ALL the list or libraries within the site. 
To me, this is a serious design flaw. You may grant users or a group Read 
access at the site level and then Contribute Access at a list/library level. 
But then if you decide they no longer need Read access to a site and delete 
them, they will 'disappear' from the list/library as well. I have some site 
admins who continously dont remember their granular permission settings and 
get themselves into trouble with the permissions. 
<quote>"
    @danielgalant: "You need to understand how permissions are applied across a SharePoint 
deployment. Security is handled at the Site Collection level and will not 
cross that particular boundary. Within the collection, however, we can go 
anywhere. (Once access has been granted of course.) Breaking inheritance at 
a sub-site, list or library, does not affect the membership of the group, 
only the permissions those people have at the sub-site, list or library. If 
group A has contribute access to site A, as well as read access to site B, 
(we are assuming same site collection and that site A and site B have broken 
inheritance) then if I add a user to group A in site B, I have also just 
given that person contribute access to site A. This is because it is the 
SAME group.
When you break inheritance in SharePoint, you really need to create new 
groups to assign permissions at the break point. This is why administration 
of permissions within a collection can become such a nightmare if you break 
inheritance all over the place. The Site permissions page will display the 
groups and people who have been granted access to this site. Deleting a 
group from here deletes the group, so if this very same group has been 
granted access somewhere else, the group is gone, wherever its being used. 
When you break inheritance you are not copying the group to the site, you 
are simply saying, if I change this groups access some place else, don't 
listen anymore.
Daniel A. Galant
Imagine what we could be... if we could just imagine.
"April" <email_address> wrote in message 
news:<email_address>
<quote>"
{'source': 'USENET', 'other_information': '{"reply_count": 3, "forum_name": "microsoft.public.sharepoint.general.20140605.mbox"}', 'file': 'data/output/usenet-microsoft.public.parquet'}