Discussion :

[STEMax]

Bonjour,

Je réitère la remarque de pvialatte, pour le moment beaucoup de réponses mais vous ne nous avez toujours pas expliqué ce que vous souhaitez faire et pourquoi vous voulez gérer dans du code vos droit au niveau d'un élément ? Afin de répondre de manière plus précise à votre question, il faudrait que nous comprenions ce que vous souhaitez faire exactement...

Cordialement,
Edgar Maucourant
Consultant / Formateur SharePoint (Admin, Dev, Fonctionnel)
http://blog.nftinside.com

[mimosa803]

Bon,

Je vais réexpliquer mon problème : Je souhaite développer un module en c# qui permet de modifier les droits d'accès d'un Item.
J'ai lu quelques tutos sur le net et j'ai vu que je peux gérer la modification et la suppression d'un item avec les events handler. Concernant la lecture d'un item je n'ai pas trouvé d'évènement qui gère ça. Alors que glucas59 m'a expliqué qu'il suffit de faire la modification et la suppression si j'ai bien compris.

Donc voilà en gros mon souci !

Merci pour votre aide tous.

[STEMax]

Bonjour,

La gestion des droits sur un élément n'est en général pas lié aux event handler, c'est pourquoi nous avons du mal à comprendre ce que vous souhaitez faire exactement.

Voici une rapide explication du fonctionnement des droits dans SharePoint.

Il existe en tout plus d'une trentaine de droits spécifiques dans SharePoint tel que : ajouter un élément, supprimer un élément, voir un élément, modifier un élément, voir les versions d'un éléments, créer des sites, voir les informations utilisateurs, etc...

Pour des raisons de simplicité d'administration ces différents droits sont regroupés dans ce que l'on appelle des niveaux d'autorisation (Permission level). Par exemple le niveau d'autorisation "Contribution" regroupe les droits "ajouter un élément", "voir un élément", "supprimer un élément" mais pas "modifier les permissions", ou "créer un site" par exemple. Suivant la version de SharePoint installée il existe plusieurs niveau d'autorisation par défault tel que "Contribution","Control Total","Lecture"... chacun ayant bien sur ses spécificités.

Ces niveaux de permissions sont affectés soit à des utilisateurs, soit à des groupes (recommandé). Cette affectation est liée également à un élément en particulier, ainsi on peut avoir ce type d'association :
Le niveau d'autorisation "Contribution" est affecté au groupe "Membre de Accueil" sur le site "Accueil" ou
Le niveau d'autorisation "Lecture" est affecté à "Jean Dupont" sur la bibliothèque "Documents Partagés".

On peut donc placer des droits à différent niveaux : Site, Bibliothèques / Listes, répertoires, éléments / documents.

Par défaut (et pour une maintenance plus aisée) chaque niveau hérite des droits de son conteneur, ainsi un document hérite des mêmes droits que la bilbliothèque qui le contient, elle-même héritant des droits du site dans lequel elle se trouve. Le site lui aussi peut très bien hériter des droits de son site parent et ainsi de suite jusq'au site de haut niveau de la collection de site.

Vous pouvez à tous les niveaux "casser" cette héritage et commencer un niveau de permissions uniques. Ainsi le groupe "Membres de Accueil" peut avoir le niveau d'autorisation "Contribution" sur le site "Accueil" sauf pour la bibliothèque "Document confidentiels" pour laquelle il a le niveau d'autorisation "Lecture". Dans cet exemple on aura des permissions uniques au niveau de la bibliothèque "Document confidentiels".

Le soucis avec les permissions uniques est que les changements opérés sur les conteneurs parents ne s'appliquent plus à l'objet ayant des autorisations uniques (et donc plus non plus à ces enfants). Ainsi dans notre exemple précédent, imaginons que je veuille ajouter un nouveau groupe "Test" sur le site qui aurait un niveau de permissions "Lecture". Cette association ne sera pas appliquée à la bibliothèque "Document confidentiels" car elle dispose de permissions uniques. Il faudra donc que je réitère la procédure pour cette bibliothèque.

On peut donc très vite se retrouver avec une maintenance ingérable si l'on a plusieurs dizaines de sites contenant eux-même plusieurs dizaines de listes et bibliothèques avec des permissions uniques. On peut même aller jusqu'à donner des permissions uniques sur un élément... Ce qui est fortement déconseillé même si cela peut être utile parfois.

Dans votre cas, si vous souhaitez donner des permissions uniques à vos éléments depuis le code, il faudra casser l'héritage en appelant sur chaque élément la méthode

BreakRoleInheritance()

Ce qui crée un niveau de permissions uniques pour l'élément. Attention par défaut l'élément n'a donc plus de permissions associées et personne ne peux le voir/modifier/supprimer... Il faut donc ensuite ajouter les permissions que vous souhaitez attribuer à l'élément. Cela implique de travailler avec plusieurs objets tel que les SPRoleDefinition (niveau d'autorisation) et les SPRoleAssignment (objet de liaison entre un groupe et un niveau d'autorisation). Je vous laisse chercher sur ces termes dans google pour trouver des articles sur le sujet.

Reste maintenant à savoir à quel moment vous souhaitez "modifier" ces droits, et c'est là que peuvent entrer en jeux les event handler (ainsi que dans d'autres cas dont je parle un peu plus loin).

Par exemple vous pourriez très bien vouloir modifier les permissions sur un élément en fonction de la valeur d'un champ, auquel cas vous devrez inclure votre code de modification dans un event handler de type ItemUpdated qui est déclenché chaque fois qu'un élément est modifié. Il existe plusieurs évènement tel que ItemAdded, ItemUpdated, ItemDeleted, etc... Mais comme vous le mentionniez il n'existe pas d'évènement pour l'affichage d'un élément (ce qui d'ailleurs n'aurait pas vraiment de sens...).

Reste à savoir donc dans quel cadre (à quel moment) votre élément doit avoir des permissions uniques, si vous pouvez répondre à cette question, vous pourrez trouver aisément où vous devrez ajouter votre code de modification des permissions.

Enfin il arrive parfois que l'on utilise les gestionnaires d'évènements pour interdire la modification ou la suppression d'un élément en fonction de règles "métier". Dans ce cas on peut utiliser un gestionnaire d'évènement synchrone (ItemUpdating, ItemDeleting,...) qui sont des évènements déclenché avant que l'action ne soit vraiment exécutée et qui permettent entre autre d'annuler cette action.

Un cas d'utilisation courant est le suivant : Dans une bibliothèque de document, si un utilisateur à le droit de suppression, il peut supprimer n'importe quel élément. Il arrive parfois que l'on veuille laisser à l'utilisateur la possibilité de seulement supprimer les documents qu'il à lui-même ajouté. Dans ce cas on peut mettre en place un event handler sur l'évènement ItemDeleting et dans cet event handler on test si l'utilisateur actuel est l'auteur du document, si ce n'est pas le cas on empèche la suppression.

Voila pour ne rapide présentation de la gestion des droits dans SharePoint, en espérant avoir été clair dans cette explication certe longue mais à mon avis essentielle.

Cordialement,
Edgar Maucourant
Consultant / Formateur SharePoint (Admin, Dev, Fonctionnel)
http://blog.nftinside.com

[glucas59]

Très bonne explication

[mimosa803]

Bonjour,

Je vous remercie beaucoup sur votre réponse ainsi tous les membres qui m'ont répondu.

[mimosa803]

Bonjour, je vous remercie pour votre aide l'autre fois concernant la gestion des droits d'un item, j'ai bien compris comment ça se passe et j'ai essayé de développer un eventhandler (ItemAddded) qui permet de donner des droits de lecture et de modification aux utilisateurs des deux champs lecteurs et modificateurs de types users que j'ai créé. En fait, quand l'utilisateur crée un nouveau item il renseigne dans les champs lecteurs et modificateurs la liste des utilisateurs qui peuvent lire et modifier son item. Puis, j'ai attaché une liste à cet eventhandler (A partir d'une interface winforms l'utilisateur choisit le site, puis la liste clique sur un bouton pour ajouter les champs lecteurs et modificateurs). Enfin il attache la liste à l'évènement.

Voilà le code de l'event handler :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
 
 
public override void ItemAdded(SPItemEventProperties properties)
        {
            this.DisableEventFiring();
            base.ItemAdded(properties);
            SPWeb web = null;
            try
            {
 
                web = new SPSite(properties.SiteId).OpenWeb(properties.RelativeWebUrl);
 
                SPListItem item = web.Lists[properties.ListId].GetItemById(properties.ListItemId);
 
                // première étape, casser l'héritage des droits
 
                item.BreakRoleInheritance(false);
 
                // seconde étape, assigner les nouveaux droits
 
                #region Ajouter les droits Control total à l'auteur
                String loginAdmin = properties.UserLoginName;
               // SPFieldUserValue userAdminValue = (SPFieldUserValue)item["Créé par"];
 
                SPUser userAdmin = web.Users[loginAdmin];
 
                SPRoleDefinition roleDefAdmin = web.RoleDefinitions.GetByType(SPRoleType.Administrator);
 
                SPRoleAssignment roleAssignementAdmin = new SPRoleAssignment(userAdmin);
 
                roleAssignementAdmin.RoleDefinitionBindings.Add(roleDefAdmin);
 
                item.RoleAssignments.Add(roleAssignementAdmin);
 
                #endregion
 
 
                #region Ajouter les droits de lecture pour les lecteurs
                SPFieldUserValueCollection usersvaluesLecteurs = (SPFieldUserValueCollection)item["Lecteurs"];
 
                for (int i = 0; i < usersvaluesLecteurs.Count; i++)
                {
                    SPUser userLecteur = usersvaluesLecteurs[i].User;
 
                    //on ajoute le user sur le dossier
 
                    SPRoleDefinition roleDefLecteur = web.RoleDefinitions.GetByType(SPRoleType.Reader);
 
                    SPRoleAssignment roleAssignementLecteur = new SPRoleAssignment(userLecteur);
 
                    roleAssignementLecteur.RoleDefinitionBindings.Add(roleDefLecteur);
 
                    item.RoleAssignments.Add(roleAssignementLecteur);
 
 
                }
                #endregion
 
                #region Ajouter les droits de modification pour les modificateurs
                SPFieldUserValueCollection usersvaluesModificateurs = (SPFieldUserValueCollection)item["Modificateurs"];
 
                for (int i = 0; i < usersvaluesModificateurs.Count; i++)
                {
                    SPUser userModificateur = usersvaluesModificateurs[i].User;
 
                    //on ajoute le user sur le dossier
 
                    SPRoleDefinition roleDefModificateur = web.RoleDefinitions.GetByType(SPRoleType.Contributor);
 
                    SPRoleAssignment roleAssignementModificateur = new SPRoleAssignment(userModificateur);
 
                    roleAssignementModificateur.RoleDefinitionBindings.Add(roleDefModificateur);
 
                    item.RoleAssignments.Add(roleAssignementModificateur);
 
                }
                #endregion
 
                item.Update();
                this.EnableEventFiring();
 
            }
 
            catch (Exception ex)
            {
 
                properties.Cancel = true;
 
                properties.ErrorMessage = "Erreur dans l'Event ItemAdded : " + ex.Message;
 
            }
 
            finally
            {
 
                if (web != null)
 
                    web.Dispose();
            }

Le problème que je n'ai pas eu un bon résultat : j'ai créé un item avec le compte de l'administrateur et j'ai ajouté dans le champs lecteurs et modificateurs le user user1. Puis, j'ai changé l'utilisateur courant en user1 pour voir l'exécution mais il n'ya pas d'Item dans la liste malgré que le user1 peut voir l'item.

J'espère que vous puissiez m'aider à trouver l'erreur.

Cordialement

[glucas59]

N'y aurait-il pas des filtres sur ton affichage ?

[mimosa803]

C'est quoi les filtres, je n'ai pas bien compris votre question.

[glucas59]

Il se peut que sur ton affichage il y ait un filtre du genre Mes documents qui fait que l'utilisateur ne voit que les documents qu'il a créé avec cet affichage.

Pour le vérifier tu sélectionnes ton affichage puis tu cliques sur le menu affichage en haut à droite de ta bibliothèque puis tu fais Modifier cet affichage.
Dans la partie filtre vérifie qu'il n'y a rien.

[mikedavem]

Bonjour,

Je me permets de compléter ce post car mon problème concerne également un problème de droits dans un eventhandler avec itemAdded.

La modification de droit s'effectue correctement sur ma liste. L'auteur de l'élément ainsi qu'un groupe SharePoint défini ont le droit de visualiser et de modifier l'élément concerné.

Mon problème est au niveau de l'affichage. Quand l'auteur de la demande créé l'élément on ne voit pas directement celui-ci. Je suis obligé de rafraichir la page pour voir l'élément apparaitre. Est ce que c'est parce que j'utilise l'événement itemAdded ?

Merci pour vos réponses

[mikedavem]

Bon la seule solution valable que j'ai trouvé , c'est d'ajouter dans l'event handler pour itemAdded qui est un événéement asynchrone une pause de 1s avant de changer les permissions.

Cela a pour effet de retarder le changement de permission. L'utilisateur voit ainsi la création de sa demande

++