Collection de sites en lecture seule: procédure et comportement

Contexte

Supposons que vous avez un programme qui extrait de l’information de plusieurs sites SharePoint. Lors de l’extraction, vous aimeriez empêcher les modifications pour la durée de l’extraction.

Procédure

Voici trois manières de procéder pour placer une collection de site en lecture seule.

Via le site d’administration :

Application Management –> Site Collection Quotos and Locks

https://community.dynamics.com/crm/b/marcellotonarelli/archive/2012/03/14/sharepoint-site-collection-lock-and-unlocking.aspx#.UYlRxbWsh8E

Via STSADM :

Mettre en lecture seule:
stsadm –o setsitelock –url http://<VotreCollectionDeSites&gt; –lock readonly

Remettre en lecture / écriture:
stsadm –o setsitelock –url http://<VotreCollectionDeSites&gt; –lock none

http://manish-sharepoint.blogspot.ca/2008/07/locking-sharepoint-site-for-readedit.html

Via l’API de SharePoint :

using (SPSite pCurSite = new SPSite(sSPSiteUrl))
{
   pCurSite.ReadOnly = bLock;
}

http://msdn.microsoft.com/en-us/library/microsoft.sharepoint.spsite.readonly.aspx

Comportement

C’est presqu’instantané de placer une collection de sites en lecture seule ou en lecture / écriture. Mais de quelle manière cela affecte-t-il vos utilisateurs?

L’interface utilisateur de SharePoint s’ajuste pour empêcher les nouvelles modifications

Par exemple, le menu contextuel d’un élément de liste devient:

Plutôt que cela:

Et le menu contextuel Actions est plus limité:

Si un utilisateur avait commencé à modifier un élément, la sauvegarde va échouer

Si l’utilisateur avait déjà commencé la saisie:

Et que le site devient en lecture seule, la sauvegarde va échouer:

Mais si l’utilisateur attend que le site redevienne en lecture / écriture, revient en arrière (via le bouton Back), il va pouvoir appliquer ses changements.

Le mode feuille de données a un comportement différent

Qu’on utilise Afficher dans la feuille de données ou Modifier dans la feuille de données, le contrôle permet de changer le texte. Cependant, la barre de statut affichera un indicateur dans le premier cas (Read-Only en bas à droite):

Si le site devient en lecture seule pendant l’édition dans la feuille de données, la sauvegarde va échouer. Voici les différentes étapes:

1) On lance la modification en mode feuille de données

2) On modifie un élément, un petit crayon apparaît à gauche

3) On place le site en lecture seule

4) On complète l’édition de la ligne en sortant de la ligne

On voit qu’il y a des erreurs. On le voit sur la ligne (icône) et dans la barre de statut.

5) On clique sur Resolve et une boîte s’affiche.

On ne peut qu’annuler nos changements et ce même si le site est revenu en lecture / écriture depuis. SharePoint rafraîchit la barre de statut pour indiquer que la grille est en lecture seule.

Je n’ai pas trouvé de manière de conserver mes modifications. On peut que les copier pour les mettre dans Excel et les remettre plus tard, lorsque le site est revenu en lecture / écriture.

Si on “colle” un grand nombre de lignes en mode feuille …

… et que le site devient en lecture seule, aucune ligne ne sera sauvegardée et la seule chose à faire sera d’annuler toutes les modifications et recommencer plus tard. C’est quand même mieux que d’avoir à distinguer celles qui ont réussi de celles qui ont échouées.

Conclusion

Si votre collection de sites n’est pas volumineuse et que votre opération d’extraction est rapide, il peut être envisageable d’effectuer un lock avant l’opération.

Les tests ont été réalisés sur Windows SharePoint Services 3.0 mais je m’attend à ce que les résultats soient similaires sous SharePoint 2010/2013. Quelqu’un l’a essayé?