Groups vs AssociatedGroups no Sharepoint 2007 (MOSS)

Programaticamente ao acedermos a um SPWeb temos duas colecções AssociatedGroups e Groups:

A principal diferença é: Groups são grupos que realmente tem algum tipo de permissão efectiva e os AssociatedGroups são na mesma grupos que podem estar criados, terem utilizadores, mas que não dão acesso a nada, apenas existem.

Portanto a colecção Groups é um sub-conjunto de AssociatedGroups.

Ao percorrer a colecção .Groups estamos a ver grupos que tem algum tipo de acesso (read, full control, etc). Se for criado um grupo e atribuir um nível de permissão, este apenas fica nos AssociatedGroups; o que quer dizer que apesar de ter um nível de permissão pré-definido não dá acesso a nada.

Ao adicionarmos esse AssociatedGroup ao SPWeb este passa a estar também nos Groups.

Para mapear estes conceitos com a interface do Sharepoint, os AssociatedGroups são os "Grupos" onde temos por omissão os proprietários, contribuintes, etc. e outros grupos criados por quem administra o site.
O facto de de estes grupos existitem não dão acesso ao utilizadores que lá se encontram adicionados.

Para um utilizador do grupo ter acesso é necessário adicionar o grupo na opção "Permissões do Site" que realmente reflecte as permissões efectivas do SPWeb.



Os AssociatedGroups depois podem ser usados para dar permissões  especificas num sub-site, lista, etc. Assim os associated groups são uma boa forma de ter uma gestão centralizada de permissões de uma aplicação baseada em moss, o problema é que a interface do moss causa alguma confusão a quem começou à pouco tempo a mexer nas permissões/segurança.

Como fazer nível de permissões "personalizadas" no Sharepoint 2007 sem necessidade de programação

No outro dia pediram-me para criar o seguinte cenário com os respectivos níveis de permissão para cada um dos SPGroups em cima de uma Document Library do MOSS.

• Um grupo que pode editar a estrutura da lista de documentos, adicionar/remover colunas etc, mas não pode ver os conteúdos (documentos e dados do SPListItem)
• Um grupo de utilizadores contribuintes que não podem modificar a estrutura das listas mas podem ver, listar, apagar, modificar.

As permissões do 2º grupo são fáceis de definir, no entanto as do 1º não. Para o efeito comecei por criar um nível de permissão no sharepoint:

Acções do Site >  Pessoas e Grupos > Permissões do Site > Niveis de Permissão > Adicionar um nível de Permissão

O problema é que ao escolher a opção "Gerir Listas - ..." automaticamente é escolhida a opção "Ver Itens - ...", o que faz sentido porque, se é possível eliminar colunas que já contém informação, pelo menos deveria ser possível ver o que se está a apagar. Mas foi expressamente pedido para fazer dessa forma, sendo assim comecei a pensar em fazer uma aplicação que programaticamente me criasse o nível pretendido. Antes de começar a programar, reparei que o Sharepoint não estava a fazer nenhum postback quando seleccionava a checkbox "Gerir Listas". Inspeccionando com o Firebug vi que a validação das dependências era feita em Javascript. Assim sendo experimentei o seguinte:

• Removi os vistos em todas as checkbox e marquei apenas a opção "Estruturar listas..." para seleccionar as dependências usuais inerentes a esta permissão
• Usando o firebug, editei o html da checkbox com a opção "Ver Itens - ..." e removi o visto retirando o html: checked=""
• Guardei as alterações...

Para minha surpresa não existe nenhuma validação do lado do servidor  do Sharepoint e realmente as alterações foram salvas, assim conseguir criar um Nível de Permissão que normalmente não conseguiria fazer OOTB (out-of-the-box).

Penso que programaticamente deveria ser possível fazer exactamente o mesmo que fiz manipulando o HTML das páginas de administração do sharepoint, realmente não faz muito sentido gerir listas sem pode ver os itens, mas como me aconteceu, o cliente pode pedir isso.