Re: Whatever happened to Site Groups in WSS 3.0?

Hi Bill, thanks for your reply.

The issue I have is that if I create specific groups for site level use,
e.g. site 1 managers, site 1 team members, site 2 managers, site 2 team
members etc. and I have many sites in the site collection I end up having an
enormous number of groups at the site collection level. We create project
specific sites for each business proposal /contract and the number of sites
soon build up.

I need to specify site specific access rather than site level, e.g. I want
user 1 to be a project manager on site 1 (giving him/her contribute access to
certain lists that are read only to team members) while the same individual
is a team member on site 2.
I can use groups to give a fixed set of users rights across many sites but
it gets messy when I want to change the members of groups depending upon
their role within each site.

I could add users with permissions given directly (e.g. ‘Contribute’ for
Team Members) then break the inheritance of permissions on certain lists and
libraries and apply different permissions at this but this would be difficult
to manage as when new users were added to sites they would also need
permissions adding to any objects that weren’t inheriting permissions from
the parent site.

Cheers

Andy


"Bill English [MVP]" wrote:

You are correct in your assessement of how group scopes have changed in WSS
v3. But I'm not clear on how this makes it difficult to secure lists and
libraries. Create the groups you need, populate them and apply them to the
list or library. Perhaps I'm missing something, but this seems
straight-forward to me.

--
Bill English, MVP
Mindsharp


"Andrew Stokes" <AndrewStokes@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:6A6BB1F0-7229-42ED-9DC4-39A23FE7C344@xxxxxxxxxxxxxxxx
Hi

In WSS 2.0 there were Site Groups and Cross Site groups. I believe Cross
Site Groups worked at the site collection level and Site Groups worked at
the
site leve. It seems that in WSS 3.0 Cross Site Groups have been
maintained,
now just termed Groups and Site Groups have been ditched. This makes life
difficult when you want to set permissions on libraries and lists in many
team sites.

In our situation, we have many project specific sites. I want the same
pool
of staff to access these sites but we want to give different permissions
to
staff depending upon their position in the project. To this end I thought
of
creating project managers, project team members and project readers groups
for each project with some lists and libraries secured to only allow the
project manager's group to modify items. The problem with this is that
groups no longer exist at the site level but seem to be at the site
collection level. This means that when you have a few hundred sites the
number of groups at the site collection level gets very quickly out of
hand.

Does anyone have any ideas besides giving individual user level
permissions
on lists and libraries that don't inherit from the site?

Cheers

Andy




.

Relevant Pages

  • Re: Setting Recipient Limits On Exchange 2003 & Group Lists
    ... recipient limits won't I still have to make sure that each individual member ... affects the settings of all of the group members. ... based lists and prevent others. ... To me that's one of the main reasons the send permissions ...
    (microsoft.public.exchange.admin)
  • Re: Delete permission issue
    ... Members of the Local Administrators group have full access to the entire ... One of the problems was of course with Lists created for the Personnel Dept, ... However, the lists have special permissions, disabling delete. ...
    (microsoft.public.sharepoint.windowsservices)
  • Name Changes & Site Collections
    ... updated with their new user info. ... the site with their new name - however if the actual permissions are examined ... list and the "Site Collection Users" lists within the site. ... they are Site Collection Owners - this needs to be manually changed as well. ...
    (microsoft.public.sharepoint.portalserver)
  • Consolidated view
    ... these lists are used to receive weekly reports from the team ... members. ... member to see other's report.The lists are identical except the permissions. ...
    (microsoft.public.sharepoint.portalserver)
  • [UNIX] Privilege Escalation Vulnerability on phpBB
    ... permissions), so although admin rights are needed to view the page, anyone ... Goto the board you wish to change the permissions for in the normal way ... Find the base directory location of the board for the script, ... This bulletin is sent to members of the SecuriTeam mailing list. ...
    (Securiteam)
Loading