Discussion :

[rigol'man]

Bonjour
Dans la continuité d'un précédent post ([SP2010] Gérer les droits de modification par document), j'aimerai savoir s'il est possible dans une page, de n'afficher certains champs que pour les membres d'un groupe Sharepoint.

J'ai créé différentes pages pour modifier les données, en fonction de qui on est :
- une pour le manager
- une pour l'équipe info

donc mon utilisateur crée sa demande, un mail est envoyé au manager avec un lien dans lequel apparait le formulaire d'édition du manager. dans le workflow qui envoie le mail, je change les droits sur le document pour que le demandeur soit lecteur et le manager soit éditeur (merci ludojojo )

ensuite, lorsqu'il valide, le document est envoyé à l'équipe info via le meme principe de mail et de lien spécifique, tout en changeant aussi les droits.

par contre, mon souci, c'est que si le manager fait des modifications et les enregistre sans envoyer le document à l'équipe info, il peut encore le modifier via la liste sharepoint, et là, le document s'ouvre en édition avec le formulaire par défaut, qui offre la possibilité de modifier tous les champs.

Or certains champs ne doivent etre modifiables que par l'équipe info, qui est représentée par un groupe sharepoint.
aurais-je un moyen de faire ca SVP ?

J'espère que j'ai été clair, n'hésitez pas à me dire si ce n'était pas le cas.
Merci

[ludojojo]

Salut,

Est ce que tu dois modifier uniquement des méta données du fichier ou le fichier lui même ?

Si c'est uniquement des méta données, tu peux faire un formulaire d'édition custom ! (sur l'item et non le document lui même)
Si en revanche il est en mesure de modifier le fichier dès la première fois (ta première étape), alors là c'est plus compliqué...

Peux-tu clarifier le besoin en nous donnant un exemple ? Type de données à modifier la première/seconde fois, attaché à l'item ou au fichier ?

[rigol'man]

avant tout, je vais poser une question bete, car venant d'un autre monde de développement (dont je tairai le nom ), je n'ai pas forcement les memes termes pour parler des memes choses.

Est ce que tu dois modifier uniquement des méta données du fichier ou le fichier lui même ?

qu'entends tu exactement par métadonnées et par fichier ?


sinon, dans mon cas, pour faire simple, j'ai une liste avec des colonnes de tout type (plusieurs lignes de texte, dates, nom, etc ....)
les x premières colonnes sont à remplir par le demandeur.
les y suivantes par le manager.
les z suivantes par l'équipe info.

J'ai fait des pages EditForm pour chaque population afin qu'ils ne voient à chaque fois que les colonnes concernées.
Mon souci, c'est que si le manager ne valide pas sa demande la première fois avec le bon formulaire, il pourra se rendre sur le site et éditer le document avec le formulaire par défaut, qui affiche toutes les colonnes.
Donc j'aurai voulu pouvoir masquer ces colonnes si on ne fait pas partir du groupe sharepoint Equipe Info.

j'ai eu un début d'idée (attention , c'est assez rare pour être noté !! ) :
dans mon EditForm par défaut, séparer les champs dans plusieurs webpart.
- premier webpart : visible par tous avec les colonnes communes à tous
- deuxième webpart : avec une audience (equipe info) et avec les colonnes réservées à ce groupe.

qu'en dites vous ?

[ludojojo]

qu'entends tu exactement par métadonnées et par fichier ?

Les méta-données sont les fameuses colonnes. Ce sont des données qui qualifient ton fichier mais qui ne sont pas contenues dans le fichier lui même !

J'ai fait des pages EditForm pour chaque population afin qu'ils ne voient à chaque fois que les colonnes concernées.

La aussi je suis pas sur qu'on ait le même vocabulaire...
Pour moi il n'existe qu'un seul editForm par type d'item (item = enregistrement dans une liste), donc par content type !
Quand tu dis, "j'ai fais plusieurs forms" tu parles de pages custom, non hébergées par la liste, qui permettent un enregistrement ?
Si c'est le cas, sâche qu'il t'es possible de tout faire dans le formulaire porté par ton content type, ce qui te permet d'avoir toutes tes règles de gestion au même endroit

Donc ton problème c'est qu'il ne passe pas forcément par ton formulaire pour éditer les méta-données... Du coup je t'invite à modifier le formulaire de ton content type afin d'être sur que ce soit la seule porte d'accès pour modifier les données, tu seras donc maitre et on ne pourra pas contourner tes règles de gestion. En tout cas, pas via l'interface graphique...

[Lapinpanda]

avant tout, je vais poser une question bete, car venant d'un autre monde de développement (dont je tairai le nom ), je n'ai pas forcement les memes termes pour parler des memes choses.
qu'entends tu exactement par métadonnées et par fichier ?


sinon, dans mon cas, pour faire simple, j'ai une liste avec des colonnes de tout type (plusieurs lignes de texte, dates, nom, etc ....)
les x premières colonnes sont à remplir par le demandeur.
les y suivantes par le manager.
les z suivantes par l'équipe info.

J'ai fait des pages EditForm pour chaque population afin qu'ils ne voient à chaque fois que les colonnes concernées.
Mon souci, c'est que si le manager ne valide pas sa demande la première fois avec le bon formulaire, il pourra se rendre sur le site et éditer le document avec le formulaire par défaut, qui affiche toutes les colonnes.
Donc j'aurai voulu pouvoir masquer ces colonnes si on ne fait pas partir du groupe sharepoint Equipe Info.

j'ai eu un début d'idée (attention , c'est assez rare pour être noté !! ) :
dans mon EditForm par défaut, séparer les champs dans plusieurs webpart.
- premier webpart : visible par tous avec les colonnes communes à tous
- deuxième webpart : avec une audience (equipe info) et avec les colonnes réservées à ce groupe.

qu'en dites vous ?

Bonjour,

comme je l'indiquai plus précédemment dans l'autre sujet, si je suis un utilisateur averti qui utilise sharepoint, tu as beau faire plusieurs formulaires, je serais toujours capable de faire de l'édition des colonnes et cela de plusieurs façon... masquer des éléments dans un formulaire n'est pas du tout une sécurité forte, la seule solution reste les event receiver sur les modifications des éléments.

Ce que vous voulez mettre en place c'est juste un habillage différent selon les utilisateurs qui permet d'éviter des modifications non voulu.

Mon souci, c'est que si le manager ne valide pas sa demande la première fois avec le bon formulaire, il pourra se rendre sur le site et éditer le document avec le formulaire par défaut, qui affiche toutes les colonnes

Par exemple, de base, si je connais l'URL EditForm.aspx, ce qui est très loin d'etre quelque chose de compliqué, vous le dites vous mêmes, cela permet d'éditer toutes les colonnes.

Votre solution reste une bonne chose, mais elle est incomplète, il faut juste en être conscient.

[rigol'man]

comme quoi, une petite remise à plat de temps en temps, ca fait pas de mal !

Les méta-données sont les fameuses colonnes. Ce sont des données qui qualifient ton fichier mais qui ne sont pas contenues dans le fichier lui même !

on n'est donc d'accord pour les méta-données, on parle bien de la même chose.
quant à ton "fichier", tu parles simplement de fichiers attachés, ou c'est encore autre chose ?

La aussi je suis pas sur qu'on ait le même vocabulaire...
Pour moi il n'existe qu'un seul editForm par type d'item (item = enregistrement dans une liste), donc par content type !
Quand tu dis, "j'ai fais plusieurs forms" tu parles de pages custom, non hébergées par la liste, qui permettent un enregistrement ?

oui je pense que c'est ça, je fais un nouveau formulaire dans ma liste, sous sharepoint designer :

Il a un nom différent, et je génère mon url avec ce nom pour que mon enregistrement soit ouvert avec ce formulaire.

Si c'est le cas, sâche qu'il t'es possible de tout faire dans le formulaire porté par ton content type, ce qui te permet d'avoir toutes tes règles de gestion au même endroit

Donc ton problème c'est qu'il ne passe pas forcément par ton formulaire pour éditer les méta-données... Du coup je t'invite à modifier le formulaire de ton content type afin d'être sur que ce soit la seule porte d'accès pour modifier les données, tu seras donc maitre et on ne pourra pas contourner tes règles de gestion. En tout cas, pas via l'interface graphique...

ok je ne fais qu'un seul formulaire d'édition, et on en revient donc à mon premier problème : comment ne pas afficher certaines méta-données (t'as vu, j'apprends vite les termes ) à une certaines population de personnes !?

[nonoxp]

Bonjour,

Si tu veux cloisonner la saisie (des metadonnees) dans un processus defini, il est tout a fait possible en natif de tout faire par ton workflow grace a l'action "Collecter les données d'un utilisateur".

La demande est creee, le workflow demarre et assigne une tache a un utilisateur (un nouvel item Tache est cree). Dans le formulaire d'edition de cette tache tu peux afficher a ton utilisateur un recapitulatif de ta demande (lecture seule).

L'item Tache contient juste les champs (metadonnees) que tu veux qu'il remplisse. Une fois la tache saisie et validee, le workflow aura la charge de mettre a jour l'item demande avec les valeurs saisies.


... sauf si d'un point de vue fonctionnel il faut que tous tes acteurs puissent avoir la possibilite d'aller modifier les metadonnees des autres acteurs de la demande a tout instant... Dans ce cas la la customisation de formulaire fera l'affaire (il y a peut etre un truc sympa a faire avec les formulaires Infopath egalement).

[rigol'man]

en fait, je dois forcément passer par le formulaire web, et pas par les taches.
c'est pour cette raison que j'ai commencé à faire des pages spécifiques pour chaque groupe d'utilisateurs ....
mon workflow n'a donc pas de validation, il me sert juste à modifier les droits d'accès et d'envoyer des mails.

[ludojojo]

quant à ton "fichier", tu parles simplement de fichiers attachés, ou c'est encore autre chose ?

Oui oui

oui je pense que c'est ça, je fais un nouveau formulaire dans ma liste, sous sharepoint designer :

Je ne connais pas bien le système de gestion de designer sur ce sujet.
Personnellement je travail avec Visual Studio dans ce cas, ce qui te permet de gérer tes problèmes de droits !

comme je l'indiquai plus précédemment dans l'autre sujet, si je suis un utilisateur averti qui utilise sharepoint, tu as beau faire plusieurs formulaires, je serais toujours capable de faire de l'édition des colonnes et cela de plusieurs façon... masquer des éléments dans un formulaire n'est pas du tout une sécurité forte, la seule solution reste les event receiver sur les modifications des éléments.

Je ne suis pas sur de voir comment tu peux modifier un item via l'interface graphique si le formulaire "EditForm" est custom, mais pourquoi pas. Je reste d'accord avec le principe, le receiver est le seul moyen de sécuriser une saisie de données !

[rigol'man]

Oui oui

J'aurai au moins compris quelque chose aujourd'hui (enfin hier) !!

Je ne connais pas bien le système de gestion de designer sur ce sujet.
Personnellement je travail avec Visual Studio dans ce cas, ce qui te permet de gérer tes problèmes de droits !

Le problème c'est que je n'ai pas assez de compétences en visual pour le faire de la sorte.

Je ne suis pas sur de voir comment tu peux modifier un item via l'interface graphique si le formulaire "EditForm" est custom, mais pourquoi pas. Je reste d'accord avec le principe, le receiver est le seul moyen de sécuriser une saisie de données !

Je suis d'accord que masquer des colonnes est loin d'être une sécurité forte.
d'un autre côté, il ne s'agit pas d'une application sensible, on veut juste que chacun remplisse sa partie et pas celle des autres.

par contre, je serai curieux de savoir comment ils pourraient modifier les données, si je ne rends visibles que les données qu'ils ont à modifier et bloque le mode feuille de données. ca pourrait me servir pour la suite.

[Lapinpanda]

Bonjour,

par contre, je serai curieux de savoir comment ils pourraient modifier les données, si je ne rends visibles que les données qu'ils ont à modifier et bloque le mode feuille de données. ca pourrait me servir pour la suite.

Sur 2010, un utilisateur qui a le droit de modifier une page, avec un bout de javascript, via SPServices qui facilite grandement l'édition, en très peu de temps on est capable de faire un script qui modifie les éléments que l'on désire, en créer, en supprimer...

Il n'y a pas besoin de droits administrateurs pour faire cela, juste la contribution, par exemple si un utilisateur fait partie de "Membres de XXX".

Edit : ce n'est pas une faille de sécurité, il s'agit d'éléments mis en place par Microsoft afin de faciliter le travail des développeurs, permettre des possibilités poussés sans avoir besoin de développer de code compilé (.DLL) sur le serveur qui sont bien plus risqué pour la ferme.

[rigol'man]

Bonjour,
Sur 2010, un utilisateur qui a le droit de modifier une page, avec un bout de javascript, via SPServices qui facilite grandement l'édition, en très peu de temps on est capable de faire un script qui modifie les éléments que l'on désire, en créer, en supprimer...

Il n'y a pas besoin de droits administrateurs pour faire cela, juste la contribution, par exemple si un utilisateur fait partie de "Membres de XXX".

Edit : ce n'est pas une faille de sécurité, il s'agit d'éléments mis en place par Microsoft afin de faciliter le travail des développeurs, permettre des possibilités poussés sans avoir besoin de développer de code compilé (.DLL) sur le serveur qui sont bien plus risqué pour la ferme.

ok merci,c'est bon à savoir. ca pourra me servir.

par contre, pour cette application, ce ne sera pas utile : les utilisateurs ciblés ont déjà du mal à créer un document, alors on a un peu de temps avant qu'ils nous pondent un bout de javascript !!!!

[ludojojo]

Sur 2010, un utilisateur qui a le droit de modifier une page, avec un bout de javascript, via SPServices qui facilite grandement l'édition, en très peu de temps on est capable de faire un script qui modifie les éléments que l'on désire, en créer, en supprimer...

Ok tu faisais référence à l'ECMA Script, dans ce cas OK. Mais tu passes de "utilisateur averti qui utilise sharepoint" à développeur.

On est bien d'accord, l'event receiver est le seul moyen incontournable sans code server.
Là n'est pas le soucis, pour ce cas particulier, je pense que tu seras obligé de mettre du code server pour réaliser et sécurisé ton besoin.
Si maintenant tu n'as pas cette possibilité, il te reste peut être une solution, mais elles sont vraiment pas génial, ce serait de supprimer du DOM Html les élements voulu, ou les désactiver etc...

Pour cela tu peux utiliser ECMA script qui te permettra de savoir si ton utilisateur courrant appartient à un groupe particulier, ou l'étape de validation de ton Workflow... Cela te permettra d'agir sur ton formulaire comme tu le souhaites.

[rigol'man]

oh bon sang, je comprends à peine un mot sur 2 !!!!
je vais vous laisser discuter entre experts !!!!

[ludojojo]

oh bon sang, je comprends à peine un mot sur 2 !!!!
je vais vous laisser discuter entre experts !!!!

Désolé...
L'ECMA Script SharePoint est un modèle Objet en JavaScript qui te permet de travailler un peu comme si tu avais du code serveur... Pour cela, tu as une petite API (très petite) qui te permet de travailler avec des objets similaires au code serveur. (les fameux SP.js ou SP.Core.js par exemple)

Pour pouvoir intéragir avec SharePoint de cette façon, l'API utilise les WebServices de SharePoint.

C'est une logique métier qui est très utilisé sur Office 365 (SharePoint Online) car la majorité du code server est interdit...
Tu peux donc utiliser cette méthode afin d'ajouter du code métier dans tes différents formulaires, ainsi tu pourras jouer avec tes champs, valeur etc...

Par contre, comme le précise Lapinpanda cette solution est un paliatif, mais une sécurisation côté serveur (event receiver) est nécessaire si tu veux être certain qu'aucun autre champ ne sera modifié...

J'espère avoir éclaircit un peu nos propos

[rigol'man]

c'est bon, je comprends 2 mots sur 3 maintenant !

merci pour les explications, je vais regarder tout ça .... à tête reposée !