[R3dKap]

Oh oui, les formulaires vont te faire gagner du temps, mais il faut savoir s’en servir.

Je te recommande vivement cette vidéo de @DavidZed sur le sujet : https://dz13n.wordpress.com/2025/02/11/les-formulaires/

😉

[R3dKap]

Salut @GREGOIRE,

C’est évident qu’ils ont fait ça “by design” (c’est voulu), même s’il reste de la place sur la ligne… Tu vas pas pouvoir faire grand chose pour ça malheureusement…

Suggestion : editer le menu de gauche sur le site pour créer une entrée pour la liste et des sous-entrées pour chacune des vues… 😉

[R3dKap]

@Shadoks_,

Quels sont les rôles de sécurité affectés aux utilisateurs sur l’environnement où se trouvent les flux ?

[R3dKap]

Salut @Sylvain,

L’algorithme va dépendre de la manière dont tu veux détecter ces 6 journées consécutives :

1. Est-ce que c’est 6 journées sur une semaine qui s’étale du dimanche au samedi ?
2. Est-ce que ces 6 journées peuvent s’étaler à cheval sur 2 semaines ?
3. Est-ce que l’algo doit retourner vrai ou faux pour ces 6 journées consécutives entre 2 dates données ?

Mais comme ça au premier abord, à supposer que l’on regarde dans toutes les occurrences de ta collection, je dirais qu’il va falloir :

• initialiser un compteur de jours consécutifs à zéro
• boucler avec un ForAll() sur les items de la collection :
  • je regarde si je trouve un item à la date D+1 par rapport à la date de l’item en cours
  • si je le trouve :
    • si le compteur est égal à 6 alors je sais que j’ai 6 jours consécutifs
  • si je ne le trouve pas c’est que je suis sur un trou -> je réinitialise le compteur de jours consécutifs à zéro

Note : pour travailler avec des variables dans une boucle ForAll() (vu qu’on ne peut ni utiliser Set() ni UpdateContext()), il faut utiliser une variable locale de type enregistrement à une colonne (par ex. : {Value: 0}) et utiliser la fonction Patch() pour la faire évoluer : Patch(locCompteur; {Value: locCompteur.Value + 1}).

Sinon, est-ce tu peux nous préciser comment est structurée et conmment fonctionne ta collection colTamponPlanningEquipier ?

[R3dKap]

@Shadoks_,

Tu n’as pas besoin de partager un flux qui est déclenché par Power Apps pour qu’un utilisateur de l’application puisse l’utiliser : le flux est exécutable par toute personne à qui l’application est partagée car c’est l’application qui lance le flux et lui transmet l’identité de l’utilisateur connecté. Dans tous mes projets, je n’ai jamais eu besoin de partager un flux… 😉

Par contre, un utilisateur de l’application ne peut pas voir un flux dans Power Automate qu’il n’a pas lui-même créé s’il n’est pas partagé avec lui.

C’est à ça que servent les options Copropriétaires et Utilisateurs avec autorisations d’exécution uniquement :

• Copropriétaires = en ajoutant ici un utilisateur tu lui donnes tous les droits sur le flux : consultation de l’historique des exécutions, modification du flux, suppression du flux
• Utilisateurs avec autorisations d’exécution uniquement = en ajoutant ici un utilisateur le flux devient visible à cet utilisateur mais ses droits sont limités :
  • il peut exécuter le flux manuellement
  • il ne peut pas voir le contenu du flux
  • il ne peut voir que ses propres exécutions et pas celles des autres, et il ne peut pas voir le détail des exécutons : il ne voit que s’il y a eu succès ou échec

Dans ton cas, le message d’erreur indique que ton flux n’a pas les droits d’accès à un composant de ta solution. Quels sont les connecteurs utilisés par ton flux ? Fait-il des trucs un peu particuliers qui pourraient expliquer qu’il y a un souci d’autorisations, comme par exemple faire appel à un connecteur custom ou ce genre de chose ?

[R3dKap]

Voilà… Le problème est là

Tu n’as pas de licence permettant l’utilisation des connecteurs premium. Il te faut l’une des 2 licences suivante :

La rouge te donne tout en illimité. La bleue te permet d’exécuter 1 application avec des connecteurs premium sur 1 environnement.

Si tu as une application qui utilise du Dataverse et que tu la déploies sur un environnement de RECETTE et de PROD, alors il te faudra 3 licences bleues : 1 pour la DEV (si c’est un environnement de type Sandbox -> pas nécessaire si c’est un environnement de type Développeur), une pour la recette, une pour la prod.

Et tu vois qu’à partir de 4 licences bleues, vaut mieux basculer direct sur la rouge.

Voilou…

• This reply was modified 2 weeks ago by  R3dKap. Reason: Précision env. DEV

[R3dKap]

Ouaich… Ca n’empêche que, personnellement, j’ai vraiment du mal à comprendre 2 choses :

• leur gestion des priorités
• la qualité de leurs tests avant mise en prod

Je trouve qu’il y a un vrai souci sur ces 2 points… Faut dire que derrière ça doit être une vrai usine à gaz…

Leur image est quand même extrêmement altérée par le manque de stabilité et de fiabilité de leurs livraisons : ils se tirent une balle dans le pied… C’est vraiment dommage passke le produit est top…

[R3dKap]

Salut @Romane,

Qu’est-ce que tu as comme licence sur l’environnement où se trouve l’application que tu veux lancer ?

[R3dKap]

Salut @François,

Comme tu as bien des colonnes de recherche dans ta liste des projets, normalement à la génération de l’application tu devrais avoir directement des listes déroulantes pour les champs Client et Site qui pointent respectivement vers tes listes Clients et Sites.

Dans la propriété Items de ces listes déroulantes tu dois avoir quelque chose qui ressemble à ça :

Choices(TaListe.TaColonne)

Est-ce que c’est bien le cas ?

Est-ce que c’est à ce niveau-là que ça coince ?

[R3dKap]

LOL… ou pas…

C’est mon quotidien depuis Juillet 2018 que je fais du Power Apps…

La liste des bugs (entre autres) que j’ai personnellement remontée au Product Group depuis 2021 :

[R3dKap]

Salut @Mick,

Lorsque tu récupères des données d’une source de données dans une collection locale dans Power Apps, il n’existe absolument aucun lien entre cette collection et ta source de données : ce sont 2 objets complètement séparés.

Cela veut dire que si tu patches ta collection, cela n’a aucune incidence sur ta source de données.

D’ailleurs, la bonne pratique est la suivante :

• je charge ma source de données dans une collection
• ma collection sert d’objet intermédiaire entre mon application et ma source de données
• mais c’est ma source de données qui reste la référence
• lorsque je modifie des données dans mon application :
  • je mets d’abord à jour ma source de données (et je gère les erreurs : car s’il y a une erreur je ne dois mettre à jour la collection)
  • s’il n’y a pas eu d’erreur lors de la mise à jour de ma source de données, alors je peux mettre à jour ma collection

Tu vois l’idée ?

Donc, dans ton cas, si tu as une collection qui contient tout ou une partie des éléments d’une liste SharePoint et que tu veux les mettre à jour, tu dois faire l’opération sur les 2 objets :

• mise à jour de la liste SharePoint avec un Patch() directement sur la liste SharePoint
• mise à jour de la collection avec un Patch() sur la collection

Mais comme expliqué précédemment, il faut gérer les erreurs : donc grosso modo, tu dois :

• faire le Patch() sur la liste Sharepoint
• et s’il n’y pas d’erreur alors tu fais le Patch() sur la collection

Ca c’est dans le cas où tu n’utilises pas de formulaire. Si tu utilises un formulaire connecté à ta liste SharePoint, le Patch() sur la collection doit se faire dans l’événement OnSuccess du formulaire. C’est ce que je fais dans 99% des cas. Il est très rare que je doive patcher une liste SharePoint : j’ai quasiment toujours un formulaire derrière.

[R3dKap]

Salut @Diane,

Non il n’est pas possible pour un flux Power Automate d’envoyer une réponse à une application de canevas Power Apps si cette dernière n’est pas à l’origine de l’exécution du flux. Une application de canevas s’exécute à un instant t avec un utilisateur qui manipule l’application ce qui provoque en général le déclenchement éventuel d’un flux. Donc si l’application ne s’exécute pas elle ne peut pas recevoir de résultat provenant d’un flux.

La question doit donc, selon moi, se poser différemment : tout traitement fait dans Power Apps peut être fait dans Power Automate -> il faut éventuellement déplacer dans un flux Power Automate le traitement qui est aujourd’hui fait dans Power Apps et qui exploite la donnée renvoyée par le site web.

Ou alors, si le résultat du traitement dans Power Apps produit une donnée stockée dans une source de données quelque part, alors il suffit que le flux qui reçoit la donnée du site web externe fasse le traitement nécessaire et stocke le résultat dans cette source de données pour qu’elle puisse être accédée ultérieurement par un utilisateur qui lançerait l’application Power Apps.

Je sais pas si ça t’aide…

[R3dKap]

J’utilise Chrome…

[R3dKap]

Salut @thomas,

Tout a l’air correct dans ton flux. En tout cas la logique est bonne.

Si tu dis que tu obtiens bien l’élément de ta liste SharePoint qui correspond à la tâche planner, il va forcément exécuter ta boucle.

Est-ce que tu peux nous mettre une capture de l’exécution pour que l’on voie à quoi ça ressemble ? Peut-être avec la boucle ouverte et l’opération dans la boucle ouverte aussi…

[R3dKap]

Ok. En fait tu dois cliquer sur le bouton Afficher tout et renseigner les champs de l’élément que tu vas créer avec les données qui proviennent de ton déclencheur… 😉