[R3dKap]

Microsoft a rassemblé sur un seul site officiel les roadmaps de l’ensemble de ses produits :

Le lien : https://www.microsoft.com/en-us/microsoft-365/roadmap

[R3dKap]

Ah… Effectivement je confirme qu’il y a eu une mise à jour de SharePoint. Pour ce qui est de la largeur des colonnes ça me surprendrais qu’elles ne soient plus enregistrées avec la vue comme c’était le cas auparavant… Sinon faut le remonter au support via un ticket…

[R3dKap]

Sauf erreur de ma part, la colonne Question de la table des réponses est une colonne de Recherche qui pointe vers ta liste des questions et donc vers un champ spécifique de cette liste : laquelle ? Title ?

C’est cette colonne-là qu’il faut que tu spécifies au niveau de Dropdown1_3 :

Dropdown1_3.Selected.LaColonneEnQuestion

Pour ce qui est de l’auditeur : quel est le type de la colonne Auditeur ? Personne ? Texte ? Si c’est texte, que stockes-tu dedans ? Adresse mail ? Nom ?

Pour info : User() est une fonction qui renvoie un ENREGISTREMENT à 4 colonnes :

Tu ne peux donc pas comparer ‘Matricule Auditeur‘ à User(). Tu me suis ? Si ton champ ‘Matricule Auditeur‘ contient un matricule qui est une donnée “custom”, où est-elle stockée dans Azure ? Dans quel champ de l’AD ?

[R3dKap]

Aaaah voilà… Parfait. A ce moment-là voici comment faire…

Sur la propriété DisplayMode du curseur, tu mets le code suivant :

If(
IsBlank(
LookUp(
AddColumns(
TestDocumentRéponseLPA;
Année;
Year(TonChampDate);
Mois;
Month(TonChampDate)
);
TonChampThème.Value=DropdownThème.Selected.Value &&
TonChampQuestion.Value=DropdownQuestion.Selected.Value &&
Année=Year(Today()) &&
Mois=Month(Today()) &&
TonChampAuditeur=UtilisateurConnecté
).RougeOrangeVert
);
DisplayMode.Edit;
DisplayMode.Disabled
)

Par contre je ne sais pas de quel type sont tes colonnes de thème, de question et d’auditeur. Donc à toi d’adapter en fonction… 😜

Pour info, le AddColumns() sert à récupérer l’année et le mois de saisie de la réponse dans des colonnes dédiées car on ne peut pas utiliser les fonctions Year() et Month() dans le LookUp() car ces fonctions ne sont pas délégables à SharePoint.

[R3dKap]

Les exemples sur des fonctions très simples sont utilisés juste pour démontrer la mécanique de la fonction Concurrent(). Mais typiquement ça n’a aucun intérêt pour des appels de fonctions Set() qui ne font que définir des constantes car celles-ci s’exécutent déjà directement en mémoire et sont donc quasi instantanée.

Par contre plus bas, il y a un exemple où la fonction Set() fait appel à un service extérieur à Power Apps (Microsoft Translator). Là ça a tout son sens… 🙂

[R3dKap]

Merci pour les éléments…

Où est saisie la réponse ? Y’a un champ en-dessous de la liste des questions pour saisir la réponse à une question choisie ?

Note : Power Apps ne permet pas de griser des éléments dans une liste déroulante. Il va donc falloir jouer sur le “grisage” du champ où on saisit les réponses. D’où ma question précédente…

Et sinon, oui effectivement il va falloir aller regarder dans la liste des réponses avec un LookUp() si l’utilisateur a déjà répondu à la question sélectionnée pour le mois et l’année en cours…

[R3dKap]

Salut David,

Comment fonctionne le système question/réponse dans ton application ?

1. Tu as a une seule liste déroulante avec les questions et un seul champ de saisie en fonction de la question choisie ?
2. Tu as plusieurs champs : un pour chaque réponse à chaque question ?

La complexité de mise en oeuvre de la solution ne sera pas la même selon le cas… 😜

[R3dKap]

Salut Maxime,

Franchement selon moi pas du tout. C’est alourdir le code et la maintenance pour rien.

La fonction Concurrent() a un réel intérêt pour paralléliser des traitements potentiellement longs. Dans 99% des cas, il s’agit de paralléliser l’accès aux données par exemple lorsque l’application démarre et qu’elle charge en collections le contenu de certaines tables de référence dont les données sont immuables.

Mais pour de simples appels à des fonctions de base Power Fx : aucun intérêt.

[R3dKap]

Salut Anthony,

Mon avis…

La mise en place de la gestion des erreurs dans un flux tel que présenté dans la vidéo de Reza (ou via toute autre méthode) DOIT être systématique. C’est nécessaire pour pouvoir mettre en place une maintenance efficace des flux. Perso je stocke les erreurs dans une liste SharePoint unique dédiée où j’indique l’environnement sur lequel l’erreur est apparue.

Pour ce qui est de donner accès aux développeurs aux flux en PROD, y’a 2 écoles :

1. Oui, ça facilite grandement les choses pour pouvoir déboguer. Mais il faut responsabiliser les DEV en leur précisant bien que toute modification est évidemment interdite (attention, malgré tout le risque de l’erreur humaine reste présent : je crois que je suis sur la DEV, je modifie le flux et en fait j’étais sur la PROD… pas très grave après, on peut en 2 clics supprimer la couche custom)
2. Non, techniquement ce n’est pas forcément nécessaire, on peut s’en passer, voire c’est peut-être plus sain de s’en passer. De base, un DEV n’est pas censé avoir accès à une PROD. Pour déboguer les erreurs de flux :
   • il lui faut le maximum de détails sur l’erreur concernée (d’où la nécessité de mettre en place un bon traçage des erreurs dans les flux)
   • il lui faut les conditions exactes dans lesquelles le flux a tourné (quelles données étaient concernées)
   • il doit être capable de reproduire le bug sur l’environnement de QUAL puis de DEV pour pouvoir le corriger

Perso, comme je suis un afficionados de la simplicité et de l’efficacité, j’ai plutôt tendance à partir sur la solution 1… 😜

[R3dKap]

Ok. Il te faut effectivement ajouter à ta liste une colonne nommée par exemple Utilisateur de type Texte (attention pas une colonne de type Personne qui est un type complexe qui va te poser des problèmes de délégation lors des requêtes depuis ton application). Dans cette colonne Utilisateur tu y stockeras l’adresse mail de l’utilisateur concerné.

Une fois que ça ce sera fait, il te suffira de récupérer la ligne correspondant à l’utilisateur connecté et d’initialiser les listes déroulantes avec les valeurs adéquates.

Pour faire ça, je te propose une solution “élégante” qui s’appuie sur les formules nommées.

• Sur l’objet App de ton application, va sur la propriété Formulas et ajoute le code suivant : nfUserData = LookUp(TalisteSP; Utilisateur = User().Email);; (n’oublie pas les 2 points-virgules à la fin)
• Si tes listes déroulantes sont des contrôles de type Liste déroulante (Dropdown), sur la propriété Default tu mets le code suivant : nfUserData.Title (pour le site de production), nfUserData.UP (pour l’UP/Service support), nfUserData.Ilot (pour l’ilot)
• Si tes listes déroulantes sont des Zones de liste déroulante (Combo box), sur la propriété DefaultSelectedItems tu mets le même code mais entre crochets : [nfUserData.Title], etc…

Voilou… Dis-nous si ça marche…

[R3dKap]

Salut David,

Oui c’est tout à fait possible. As-tu une table Dataverse ou une liste SharePoint où sont renseignées les informations associées à chaque utilisateur ? Si oui, peux-tu nous décrire les colonnes qu’elle contient ?

[R3dKap]

Salut Ilies,

C’est parce-qu’il s’agit de 2 contrôles différents :

• la liste déroulante, qui ne permet pas de faire de recherche
• la zone de liste déroulante qui permet de faire de la recherche

Regarde bien dans le menu Insérer :

😉

[R3dKap]

Déjà ?! 😂

[R3dKap]

Ok, alors essaie ceci :

<pre class=”language-markup”>Sum(
Filter(
Prestations;
Ligne.Id in ShowColumns(
Filter(
Lignes;
Commande.Id = Gallery8.Selected.ID
);
ID
)
);
Temps
)

Je te laisse mettre les bons noms de listes et de colonnes. ATTENTION à bien respecter les majuscules et minuscules entre ID et Id…😉
Explications (on lit toujours une formule de l’intérieur vers l’extérieur) :

• on filtre d’abord la liste des lignes correspondant à la commande
• ensuite on restreint le résultat à la seule colonne ID pour pouvoir utiliser l’opérateur in
• puis, on filtre les lignes de prestations sur la base des lignes identifiées précédemment
• et enfin on somme le temps passé

Dans cette formule tu vas avoir un problème de délégation car la fonction Filter() n’est pas capable de déléguer à SharePoint une condition du type ChampLookup.Id. Donc si tu as un jour plus de 2000 lignes dans ta liste Lignes ou ta liste Prestations, le résultat sera partiel voire vide, donc incorrect.

Pour contourner ce problème je te recommande d’ajouter dans chacune de ces 2 listes une colonne qui va contenir l’ID de la donné liée. Soit :

• Dans la liste Lignes : une colonne CommandeID de type numérique qui va stocker l’ID de la commande concernée
• Dans la liste Prestations : une colonne LigneID de type numérique qui va stocker l’ID de la ligne de commande concernée

Ca fait un peu redondance mais je me l’autorise pour régler les pronlèmes de délégation ou faciliter les opérations de filtrage des données.

Alors tu pourras écrire la formule ci-dessus comme ceci et tu n’auras plus de problème de délégation :

<pre class=”language-markup”>Sum(
Filter(
Prestations;
LigneID in ShowColumns(
Filter(
Lignes;
CommandeID = Gallery8.Selected.ID
);
ID
)
);
Temps
)

Autre piste d’amélioration : ajouter directement une colonne CommandeID à ta liste Prestations pour éviter de devoir filtrer la liste Lignes. Tu pourrais alors simplement écrire :

<pre class=”language-markup”>Sum(
Filter(
Prestations;
CommandeID = Gallery8.Selected.ID
);
Temps
)

Voilou… N’hésite pas si tu as encore des questions…

[R3dKap]

Super. Merci pour le détail.

Question importante : est-ce qu’il peut y avoir plusieurs lignes dans Prestations qui pointent vers la même ligne de commande ? C’est à dire : est-ce qu’il peut y avoir plusieurs personnes qui réalisent la même ligne de commande ?

Sinon une remarque : pourquoi ton Sort() sur Gallery8 trie sur la colonne Nom qui n’existe pas dans ta liste des Commandes ? N’y a-t-il pas confusion entre le nom du client et le n° de la commande (qui doit être la colonne Commande je suppose).