...sans une ligne de code!
(enfin, à part un minimum d'édition HTML)
C'était un problème qui m'achalait depuis un bon bout de temps. Les clients voulaient ça: qu'un usager Admin puisser créer un item de liste pour une autre personne. C'est important, car la sécurité de base Sharepoint fait en sorte qu'un usager régulier ne voit que ce qu'il a créé. Bref, si un admin crée un item, il est à son nom et l'usager régulier ne le voit pas (alors que l'inverse est ok: l'usager régulier peut créer de quoi que l'admin va voir, justement parce qu'il est admin).
Comment régler ça?
Voici la solution illustrée. Certaines valeurs ont été brouillées délibérément question de garder la confidentialité.
Ceci se basera sur l'exemple d'une liste Sharepoint 2010 nommée MaListe qui ne contient que le champ Title (par défaut). La présence ou l'absence d'autres champs ne devrait rien changer.
1- Dans Sharepoint Designer (download gratuit de Microsoft), ouvrir le site et choisir la liste MaListe
2- Créer un nouveau formulaire (au milieu à droite) qu'on nommera ici Assignation. C'est un formulaire d'édition, mais pas par défaut. Cocher la case pour créer le lien et lui donner son libellé (pour faire original, Assignation).
3- Dans le formulaire, ajouter une nouvelle ligne après le premier champ. Supprimer les lignes subséquentes (on veut que ce formulaire d'édition change seulement le champ Author, pas les autres alors aussi bien les enlever). Le champ Title peut rester à titre informatif (comme quoi l'usager sait ce qu'il modifie).
4- Aller en mode édition du code (pour voir le HTML). Trouver la ligne qu'on vient d'ajouter (ça devrait suivre Title). Ça devrait ressembler à
<tr>
<td valign="top" class="ms-formlabel" width="190px">
<xsl:text xmlns:ddwrt="http://schemas.microsoft.com/WebParts/v2/DataView/runtime" ddwrt:nbsp-preserve="yes" disable-output-escaping="yes">&nbsp;</xsl:text>
</td>
<td valign="top" class="ms-formbody" width="400px">
<xsl:text xmlns:ddwrt="http://schemas.microsoft.com/WebParts/v2/DataView/runtime" ddwrt:nbsp-preserve="yes" disable-output-escaping="yes">&nbsp;</xsl:text>
</td>
</tr>
5- Remplacer ceci par:
<tr>
<td width="190px" valign="top" class="ms-formlabel">
<H3 class="ms-standardheader"><nobr>Nouveau créateur</nobr></H3>
</td>
<td width="400px" valign="top" class="ms-formbody">
<SharePoint:FormField runat="server" id="ff2{$Pos}" ControlMode="Edit" FieldName="Author" __designer:bind="{ddwrt:DataBind('u',concat('ff2',$Pos),'Value','ValueChanged','ID',ddwrt:EscapeDelims(string(@ID)),'@Author')}"/>
<SharePoint:FieldDescription runat="server" id="ff2description{$Pos}" FieldName="Author" ControlMode="Edit"/>
</td>
</tr>
ATTENTION! ff2 est ici un indicateur qui doit être unique d'un champ à l'autre. Si vous gardez plusieurs contrôles sur votre formulaire, cet indicateur devra être différent sur votre formulaire (prenez le plus haut ff + 1)
Ce que ça fait:
-Une première colonne nommée Nouveau créateur
7- Sur le site Sharepoint, Dans le menu contextuel, Assignation devrait maintenant être là.
8- On peut donc choisir la valeur... et le travail est fait. (je sais que c'est brouillé, mais ça marche, promis!)
Notes de développement
Un recueil de notes de développement sur Access, Sharepoint, CRM et autres...
2012-07-30
2011-01-26
Upload d'Excel vers Sharepoint 2010 - les mésaventures du copier-coller.
Petite opération triviale cette semaine qui a eu un petit contretemps. J'ai monté un gabarit de liste Sharepoint pour un client, rien de compliqué (une liste avec 6-7 champs, c'est tout). Le client aime, approuve, et demande qu'on transfère ses données Excel dans la liste.
Dans IE, c'est normalement une opération triviale aussi compliquée qu'un copier-coller. Il s'agit juste d'ouvrir la liste, de passer en mode feuilles de données et de faire ledit copier-coller.
Sauf que...
Dans le document Excel, j'ai un champ de long texte. J'ai créé son équivalent "Multiple lines of text" dans Sharepoint. pour pouvoir avoir les possibilités de texte enrichi (demandées par le client).
Et rien à faire, le copier-coller massif de plusieurs lignes ne fonctionne pas pour ce champ.
Solution simple: Copier-coller individuel. Dans la démo, j'avais 15-20 lignes, alors en quelques minutes c'était fait. Mais là j'en ai nettement plus, assez pour dire que
-C'est long
-C'est platte
-Plus on en fait, plus on ajoute de risques d'erreur
Solution à peine moins simple: une requête SQL. Bon, j'ai déjà eu accès à la BD SQL Server de Sharepoint et c'est assez spectaculairement mal fichu. Pas aussi pire que Great Plains, mais pas fort non plus.
Mais... mon vieil ami Access me permet de régler ça facilement. Depuis la version 2003 (qui reste ma version préférée d'Access), c'est possible de linker une liste Sharepoint (2007 ou 2010). Suffit de rentrer la bonne adresse, les credentials et voilà, tout le monde est content.
Mon idée est donc d'utiliser le mode feuilles de données de Sharepoint pour tous les champs, sauf celui qui ne marche pas (ma fameuse description longue). Ensuite, dans Access, j'importe juste les descriptions longues dans une autre table. Je lie les deux tables, requête update et voilà, c'est fait.
Mais comment linker les deux tables? Dans Excel, j'aurai pas accès à mon ID Sharepoint qui sera généré juste au moment d'insérer.
Je ne me suis pas cassé la tête, j'ai utilisé une méthode aussi simple qu'inefficace. J'ai ajouté une colonne dans Excel, donnant un numéro à chaque ligne ensuite (1, 2, 3, ...). Juste besoin de rentrer les trois premières lignes à bras et ensuite un drag and drop de ces cellules jusqu'à la fin, ça se fait en un rien de temps. Ensuite avant de faire un copier-coller dans Sharepoint, je crée une colonne NoTemp pour ça. Je fais mon copier coller, ça se remplit (attention: une ligne masquée dans Excel (hauteur = 0) ne sera pas prise en compte.
Ensuite je fais le même principe avec seulement la colonne NoTemp d'Excel et le texte de la description longue. Copier-coller, mais cette fois dans Access dans une table (paste append).
Ensuite c'est un jeu d'enfant de linker mes deux tables par NoTemp et de faire une requête Update... et évidemment, ensuite, d'aller supprimer dans Sharepoint ma colonne NoTemp temporaire pour éviter au client de voir ça!
Bref, pas mal de zigonnage pour quelque chose qui aurait dû être plus simple.
Dans IE, c'est normalement une opération triviale aussi compliquée qu'un copier-coller. Il s'agit juste d'ouvrir la liste, de passer en mode feuilles de données et de faire ledit copier-coller.
Sauf que...
Dans le document Excel, j'ai un champ de long texte. J'ai créé son équivalent "Multiple lines of text" dans Sharepoint. pour pouvoir avoir les possibilités de texte enrichi (demandées par le client).
Et rien à faire, le copier-coller massif de plusieurs lignes ne fonctionne pas pour ce champ.
Solution simple: Copier-coller individuel. Dans la démo, j'avais 15-20 lignes, alors en quelques minutes c'était fait. Mais là j'en ai nettement plus, assez pour dire que
-C'est long
-C'est platte
-Plus on en fait, plus on ajoute de risques d'erreur
Solution à peine moins simple: une requête SQL. Bon, j'ai déjà eu accès à la BD SQL Server de Sharepoint et c'est assez spectaculairement mal fichu. Pas aussi pire que Great Plains, mais pas fort non plus.
Mais... mon vieil ami Access me permet de régler ça facilement. Depuis la version 2003 (qui reste ma version préférée d'Access), c'est possible de linker une liste Sharepoint (2007 ou 2010). Suffit de rentrer la bonne adresse, les credentials et voilà, tout le monde est content.
Mon idée est donc d'utiliser le mode feuilles de données de Sharepoint pour tous les champs, sauf celui qui ne marche pas (ma fameuse description longue). Ensuite, dans Access, j'importe juste les descriptions longues dans une autre table. Je lie les deux tables, requête update et voilà, c'est fait.
Mais comment linker les deux tables? Dans Excel, j'aurai pas accès à mon ID Sharepoint qui sera généré juste au moment d'insérer.
Je ne me suis pas cassé la tête, j'ai utilisé une méthode aussi simple qu'inefficace. J'ai ajouté une colonne dans Excel, donnant un numéro à chaque ligne ensuite (1, 2, 3, ...). Juste besoin de rentrer les trois premières lignes à bras et ensuite un drag and drop de ces cellules jusqu'à la fin, ça se fait en un rien de temps. Ensuite avant de faire un copier-coller dans Sharepoint, je crée une colonne NoTemp pour ça. Je fais mon copier coller, ça se remplit (attention: une ligne masquée dans Excel (hauteur = 0) ne sera pas prise en compte.
Ensuite je fais le même principe avec seulement la colonne NoTemp d'Excel et le texte de la description longue. Copier-coller, mais cette fois dans Access dans une table (paste append).
Ensuite c'est un jeu d'enfant de linker mes deux tables par NoTemp et de faire une requête Update... et évidemment, ensuite, d'aller supprimer dans Sharepoint ma colonne NoTemp temporaire pour éviter au client de voir ça!
Bref, pas mal de zigonnage pour quelque chose qui aurait dû être plus simple.
2010-12-22
Comment créer une relation parent-enfant dans un formulaire Sharepoint 2010
Pour ce premier article, un petit truc simple qui m'a fait perdre un peu trop de temps à mon goût au bureau.
Besoin:
On a une liste d'items. Chacun de ces items peut avoir de 0 à N suivis. Bref, la traditionnelle relation many-to-one. Facile à faire dans plusieurs situations, mais dans Sharepoint, un peu moins. Différents blogs traitent d'infos du genre, mais ce n'est pas toujours évident et/ou bien expliqué.
Solution:
1- Créer une liste "Parent". Pour les besoins de l'exemple, pas besoin d'ajouter de colonnes autres que celles par défaut.
2- Créer une liste "Enfant". Garder les champs par défaut, mais ajouter une colonne "Parent". Cette colonne est de type Recherche (lookup), lié au champ Titre de la liste "Parent". Ce champ devrait être obligatoire.
Note: J'ai créé 2-3 items dans chaque liste avant d'aller plus loin.
3- Créer un affichage (vue) de la liste "Enfant". Prendre affichage standard dans les choix. Garder uniquement la colonne "Titre". Personellement je l'ai nommé "TitreSeulement", facile à retenir...
4- Aller dans les outils de liste pour la liste "Parent". À droite, cliquer sur le bouton "Modifier les composants WebPart formulaire". Cliquer ensuite sur le choix (très mal traduit) "Afficher le formulaire par défaut" (ça devrait être "formulaire d'affichage par défaut").
5- Dans "Outils de page", cliquer sur "Liste associée". La liste "Enfant" devrait apparaître comme choix juste en-dessous, la sélectionner. Elle va apparaître dans le formulaire.
6- À la droite complètement de ce qui a été ajouté se trouve (si on passe la souris) un triangle noir. Cliquer pour accéder à "Modifier le composant WebPart". Dans la fenêtre de propriétés qui va apparaître, Dans le champ "Affichage sélectionné", prendre la vue créé à l'étape 3 ("TitreSeulement").
7- Sortir du mode édition. Tout devrait être fonctionnel.
Il me reste à trouver comment faire en sorte qu'à la création d'un enfant, le parent soit défini par défaut dans la liste déroulante.
Merci à ce site où j'ai trouvé une bonne partie de la réponse.
Besoin:
On a une liste d'items. Chacun de ces items peut avoir de 0 à N suivis. Bref, la traditionnelle relation many-to-one. Facile à faire dans plusieurs situations, mais dans Sharepoint, un peu moins. Différents blogs traitent d'infos du genre, mais ce n'est pas toujours évident et/ou bien expliqué.
Solution:
1- Créer une liste "Parent". Pour les besoins de l'exemple, pas besoin d'ajouter de colonnes autres que celles par défaut.
2- Créer une liste "Enfant". Garder les champs par défaut, mais ajouter une colonne "Parent". Cette colonne est de type Recherche (lookup), lié au champ Titre de la liste "Parent". Ce champ devrait être obligatoire.
Note: J'ai créé 2-3 items dans chaque liste avant d'aller plus loin.
3- Créer un affichage (vue) de la liste "Enfant". Prendre affichage standard dans les choix. Garder uniquement la colonne "Titre". Personellement je l'ai nommé "TitreSeulement", facile à retenir...
4- Aller dans les outils de liste pour la liste "Parent". À droite, cliquer sur le bouton "Modifier les composants WebPart formulaire". Cliquer ensuite sur le choix (très mal traduit) "Afficher le formulaire par défaut" (ça devrait être "formulaire d'affichage par défaut").
5- Dans "Outils de page", cliquer sur "Liste associée". La liste "Enfant" devrait apparaître comme choix juste en-dessous, la sélectionner. Elle va apparaître dans le formulaire.
6- À la droite complètement de ce qui a été ajouté se trouve (si on passe la souris) un triangle noir. Cliquer pour accéder à "Modifier le composant WebPart". Dans la fenêtre de propriétés qui va apparaître, Dans le champ "Affichage sélectionné", prendre la vue créé à l'étape 3 ("TitreSeulement").
7- Sortir du mode édition. Tout devrait être fonctionnel.
Il me reste à trouver comment faire en sorte qu'à la création d'un enfant, le parent soit défini par défaut dans la liste déroulante.
Merci à ce site où j'ai trouvé une bonne partie de la réponse.
S'abonner à :
Messages (Atom)