Tag

Sintomi: ogni volta che un utente con permessi di contribuzione su un elemento (lista o raccolta che fosse) provava ad aprire il menu contestuale, SharePoint restituiva questo bellissimo messaggio:

ItemNoLongerAvailable

Cliccando direttamente sul link all’item o al documento, le funzionalità di contribuzione erano comunque disponibili.

Googolando un po’ l’errore, ho trovato questi 2 casi simili:

… ma per quanto simili, non uguali.

Scenario: I permission levels di default (Full Control, Contribute, Read) non erano stati modificati. Il contesto prevedeva che ci fosse una gestione granulare dei permessi (quindi all’interno della stessa lista c’erano permessi di scrittura/modifica/lettura diversi sui singoli elementi ). In particolare, la logica dell’ereditarietà dei permessi era stata rotta sia a livello di lista (che quindi aveva permessi esclusivi rispetto al sito in cui si trovava), sia a livello di singoli elementi (“paradossalmente”, chi aveva diritti sui singoli elementi, poteva non averne sulla lista di appartenenza).

Ma SharePoint come si comporta quando si rompe l’ereditarietà dei permessi?

Assegna agli utenti il famigerato “Limited Access” per consentire agli utenti con permessi esclusivi su determinati elementi di attraversare le zone rosse (virtualmente, è come se l’utente fosse bendato durante il tragitto, per poi riacquisire la vista una volta  giunto a destinazioneSorriso – per chi volesse approfondire la dinamica, consiglio questo bel post: SharePoint – Limited Access – What is it?).

Limited Access is a special permission level that cannot be assigned to a user or group directly. The reason it exists is because if you have a library or subsite that has broken permissions inheritance, and you give a user/group access to only that library/subsite, in order to view its contents, the user/group must have some access to the root web. Otherwise the user/group will be unable to browse the library/subsite, even though they have rights there, because there are things in the root web that are needed to render the site or library. Therefore, when you give a group permissions only to a subsite or library that is breaking permissions inheritance, SharePoint will automatically give Limited Access to that group or user on the root web.

Nel caso specifico, però, il Limited Access assegnato non comprendeva il singolo permesso “View Application Pages” e questo causava l’errore.

LimitedAccessLockDownFeature

Ma com’è stato possibile, soprattutto considerando che il Limited Access non è un permission level modificabile?

Questo post “Limited access” and default permission levels vs. lockdown mode (SharePoint 2010) segnalato da Riccardo nella nostra knowledge base interna è stato illuminate: Le lock down features!

Andando a ritroso, ho scoperto che la Intranet era stata creata partendo da un Publishing Site, che, di default, ha le lock down features attivate:

LockDown

(per vedere le features attive: da POhS:
get-spfeature -site http://sitecollectionURL;

per vedere il template di sito utilizzato:

$web = Get-SPWeb http://portal
write-host “Web Template:” $web.WebTemplate ” | Web Template ID:” $web.WebTemplateId
$web.Dispose()

Disabilitando la feature (inutile nel caso specifico, dato che la intranet non necessitava accesso anonimo e la conseguente inibizione dell’accesso alle pagine applicative):

$lockdown = get-spfeature viewformpageslockdown disable-spfeature $lockdown -url http://sitecollectionURL

il Limited Access è tornato consono rispetto alle funzionalità di una Intranet:

LimitedAccessNoLockDownFeature

La morale è: per una Intranet, non partite da un Publishing Portal (ma magari da un Team site nel quale successivamente attiverete Publishing Infrastructure e Publishing Features); e se proprio lo fate e non vi serve l’accesso anonimo, disabilitate le lock down features (onde evitare effetti indesiderati!!!)