[R3dKap]

Salut @Dany,

Tout dépend de ce que tu appelles les “derniers” enregistrements : quelle est l’élément qui permet de les classer et de les considérer comme premiers ou derniers ?

Parce-que la fonction Sort() est déléguable à SharePoint (du moment que tu ne tries pas sur une colonne complexe) : ce qui veut dire que si tu veux récupérer des lignes parmi les 2000 derniers enregistrements d’une liste qui en contient 1 000 000, tu fais d’abord un Sort() et ensuite tu filtres :

Filter(Sort(Ma_Liste_SharePoint; DateEnreg; SortOrder.Descending); varUserMail in emails_bo)

Bon, ça n’empêchera pas le “in” de ne pas être déléguable…

[R3dKap]

Salut @Lilian,

Essayons déjà de résoudre un problème majeur ici 😅 : je n’ai jamais entendu parler de DataEntity ni dans SharePoint, ni dans Power Apps.

Est-ce que tu peux nous mettre une capture d’écran qui nous montre ce que c’est que ce truc-là ?

🙏

[R3dKap]

Ah bin oui là avec cette url il va rien se passer.

Est-ce que tu peux nous décrire le plus précisément possible quelles manipulations tu fais pour arriver à cet écran vide ? Tu essaies de créer une nouvelle application ? Où cliques-tu ? Tu essaies de modifier une application existante ? Comment fais-tu ?

N’hésite pas à mettre des captures ou faire une p’tite vidéo pour nous montrer… 😉

[R3dKap]

Avec plaisir @Fiona… 😉

[R3dKap]

Ok… Evidemment, il faudrait que je comprenne tous les tenants et aboutissants du fonctionnement et du mouvement de vos pièces de rechange pour bien cerner l’objectif…

[R3dKap]

Ok, je vois ce que tu veux faire. Mais avant de te détailler mes suggestions de réalisations, quelques informations importantes sur la logique et l’architecture générale de ton application :

• un contrôle Formulaire (constitué de datacards, eux-même constitutés des 4 contrôles habituels : DataCardKey, DataCardValue, ErrorMessage, StarVisible) est un objet semi-automatisé qui permet de manipuler un enregistrement d’une source de données (liste SharePoint, table Dataverse, table SQL, …) -> un Formulaire ne peut pas travailler avec une collection
• lorsqu’un contrôle Formulaire est placé sur un écran, la bonne pratique veut que l’on fasse l’appel au SubmitForm() soit lors du clic sur un bouton, soit lorsque l’on quitte l’écran -> on ne fait pas de SubmitForm() sur un formulaire qui ne se trouve pas sur l’écran actif !
• donc concrètement :
  • soit tu utilises des contrôles Formulaire qui sont branchés sur tes listes SharePoint et à chaque fois que tu quittes un écran ou lors d’un clic sur un bouton tu fais ton SubmitForm() (c’est ce que j’ai plus ou moins décris dans mon post précédent)
  • soit tu gères tes enregistrements via une collection et à ce moment-là tu n’utilises pas le contrôle Formulaire, tu construis toi-même tes formulaires de saisies en plaçant des libellés et des listes déroulantes ou des zone de texte sur tes écrans, et tu enregistres les données de ta collection via la fonction Patch() (mais c’est fastidieux car faut tout gérer “manuellement” : les messages d’erreurs, les réinitialisations de chaque contrôle au changement d’enregistrement, etc.)

<hr>

Maintenant il faut qu’on parle de ta liste SharePoint : il faut la revoir car tu mélanges dedans 2 notions différentes :

• les données générales de l’audit (client, auditeur, processus, commentaires, date de l’audit)
• les données des étapes (étape, description, responsable, notes)

Le problème avec ta liste actuelle c’est que tu as mis tous ces champs dans la même liste -> comme tu as un enregistrement par étape, tu vas répéter les données générales autant de fois qu’il y a d’étapes dans l’audit. Tu me suis ?

Il faut donc séparer ces notions dans 2 listes distinctes de la manière suivante :

• Liste AUDITS
  • Client
  • Auditeur
  • Processus
  • Commentaires
  • Date de l’audit
• Liste ETAPES
  • Audit (colonne de recherche qui pointe vers la liste AUDITS)
  • Etape
  • Description
  • Responsable (peut être différent de l’auditeur ? sinon inutile)
  • Notes

Bien définir ton modèle de données est crucial pour te faciliter la vie ensuite dans la construction de l’application.

<hr>

Perso ce que j’aurais bien vu en terme d’architecture pour ton appli c’est les écrans suivants :

• ACCUEIL
  • Affiche la liste des audits dans une galerie
  • Quand on clique sur un audit on arrive sur l’écran DETAILS AUDIT
  • Un bouton NOUVEL AUDIT qui amènerait l’utilisateur sur l’écran AUDIT en mode création
• DETAILS AUDIT
  • Un encart avec un rappel des données générales de l’audit sélectionné
  • Une galerie qui récapitule les étapes de l’audit cliqué
  • Ici à toi de voir si tu autorises de modifier les données générales de l’audit (auquel cas il y aurait un bouton MODIFIER L’AUDIT et on se brancherait en modification sur l’écran AUDIT)
  • A voir aussi si tu autorises de modifier les étapes de l’audit (auquel cas il y aurait un bouton MODIFIER LES ETAPES et on se brancherait en modification sur l’écran ETAPES)
• AUDIT
  • Un formulaire branché sur ta liste AUDITS qui se positionne en mode création
  • Ton bouton DEMARRER L’AUDIT qui effectue le SubmitForm() et qui amène l’utilisateur sur l’écran ETAPES en mode création (pour créer à minima la première étape)
• ETAPES
  • Un formulaire branché sur ta liste ETAPES et qui fonctionne plus ou moins comme je l’ai décris dans mon post précédent.
  • J’ajouterai un bouton SUPPRIMER ETAPE pour se débarrasser d’une étape si nécessaire et je séparerai la notion d’étape suivante de la notion de nouvelle étape : donc je ferais un bouton NOUVELLE ETAPE et le bouton ETAPE SUIVANTE serait grisé lorsque l’on est sur la dernière étape.
  • Le bouton TERMINER AUDIT qui ramène soit à l’ACCUEIL soit sur l’écran DETAILS AUDIT

Tu vois que pour moi les données s’enregistrent au fur et à mesure qu’elles sont manipulées. Et ce que je ferais c’est que je mettrais en place dans la liste AUDITS une colonne STATUT qui me permette de savoir si un audit est en cours ou s’il est terminé et qu’on ne peut plus le modifier.

Le truc c’est que tout ça dépend de la manière dont les audits se passent dans la vie réelle et quelles sont les règles de gestion associées. Comme je ne sais pas comment ça se déroule, je fais des suppositions. Typiquement :

• Est-ce qu’un audit peut être interrompu et repris plus tard ? Ne faut-il donc pas un statut de l’audit ?
• Peut-on supprimer des étapes ? Que se passe-t-il pour la numérotation des étapes dans ce cas ?
• Jusqu’à quel point un audit peut-il être modifié/rectifié ?
• etc…

En tout cas, pour répondre à l’une de tes remarques, fonctionner comme ça te permettrait quoiqu’il arrive de pouvoir revenir en arrière sur une étape pour la corriger.

<hr>

Non, la collection n’est pas du tout un élément requis au fonctionnement d’une application Power Apps. Tu peux très bien développer une application Power Apps qui n’utilise aucune collection et qui se “branche” uniquement directement sur les sources de données.

[R3dKap]

Salut @CedZ,

Q1. Pourquoi utilises-tu une collection AuditData ? Pourquoi ne pas travailler directement avec la liste SharePoint ? Passer par une collection complexifie la mécanique (mais peut-être y a-t-il une bonne raison).

Q2. Est-ce que les numéros d’étapes se suivent parfaitement d’un enregistrement à l’autre (sans trous) ? Que se passe-t-il au niveau de la numérotation si on supprime une étape ?

Q3. Qu’as-tu mis pour l’instant dans la propriété Item de ton formulaire ?

Q4. Comment remplis-tu aujourd’hui ta collection AuditData ?

Q5. Qu’as-tu prévu si l’utilisateur a commencé à saisir des données sur l’enregistrement en cours et qu’il clique sur PRECEDENT ? Popup de confirmation ? Il perd ce qu’il a saisit ? Enregistrement automatique ? Et si des champs obligatoires sont vides ?

Q6. Est-ce que le numéro d’étape est automatique et verrouillé ou il est saisi par l’utilisateur ? Que se passe-t-il s’il saisit un numéro complètement décalé avec le n° précédent et le suivant ?

—————-

Par rapport à ton code…

PRECEDENT

Les lignes Last(FirstN(...)) ne servent à rien ici puisque le résultat n’est renvoyé nulle part, ni dans une variable, ni placées dans une propriété d’un contrôle (ou peut-être ne l’as-tu pas précisé).

SUIVANT

Dans ton Collect() tu alimentes des colonnes avec des datacards “complets” (c’est-à-dire avec tous les contrôles qu’il y a dedans). C’est pas comme ça qu’on fait. Il faut que tu utilises les DataCardValueXXX qui sont les contrôles qui portent les saisies de l’utilisateur (listes déroulantes, zone de texte, etc.).
Donc par exemple :

Collect(
AuditData;
{
Etape: DataCardValue3.Text;
Responsable: DataCardValue4.Text;
Notes: DataCardValue5.Text
}
)

Le plus souvent les développeurs ne renomment pas les DataCardValueXXX donc là j’ai mis n’importe quel numéro. Faudra mettre les tiens… 😉

Mais concrètement, pour ce que tu cherches à faire je ferais comme ceci :

• Champs obligatoires : Etape, Description, Responsable
• Sur le OnVisible de l’écran : UpdateContext({numEtape: 1});; Reset(Form1);; (on démarre à l’étape 1 et on réinitialise le formulaire)
• Sur le Item du formulaire : Last(FirstN(Sort(TaListeSP; Etape); numEtape)) (il faut bien trier la liste sur les étapes avant d’accéder à l’élément en cours sinon on sera pas sur le bon enregistrement)
• Sur le DefaultMode du formulaire : If(numEtape > CountRows(TaListeSP); FormMode.New; FormMode.Edit) (en gros si on est sur une étape au-delà des étapes existantes c’est qu’on a cliqué sur le bouton SUIVANT alors qu’on était déjà sur la dernière étape existante -> donc on crée une nouvelle étape)
• Sur le OnSelect du bouton PRECEDENT : UpdateContext({indexationEtape: -1});; SubmitForm(Form1);; (la variable indexationEtape va être ajoutée à la variable numEtape pour avancer ou reculer dans les étapes selon le bouton cliqué)
• Sur le OnSelect du bouton SUIVANT : UpdateContext({indexationEtape: 1});; SubmitForm(Form1);;
• Sur le OnSuccess du formulaire : UpdateContext({numEtape: numEtape + indexationEtape});; ResetForm(Form1);; (le changement d’étape ne doit se faire que si le formulaire a bien été enregistré -> c’est à ça que sert l’événement OnSuccess du formulaire : ainsi, tant qu’il y aura des champs obligatoire non renseignés, l’utilisateur restera bloqué sur l’étape en cours)
• Sur le DisplayMode du bouton PRECEDENT : If(numEtape > 1; DisplayMode.Edit; DisplayMode.Disabled) (ça c’est histoire de verrouiller le bouton PRECEDENT si on est sur la première étape)

Voilou… J’ai p’têt oublié des trucs… Et c’est en supposant que c’est bien la logique que tu voulais mettre en place… 😉

[R3dKap]

Salut @Fiona,

Tu dois écrire ta formule comme ceci :

ClearCollect(
colGriDataConv;
AddColumns(
RenameColumns(
ShowColumns(
ListeFormation;
IdBis;
Cursus;
CFR;
CFA;
DateDebut;
DateFin;
Statut
);
IdBis;
Identifiant;
DateDebut;
'Date de début';
DateFin;
'Date de fin'
);
Convocation;
""
)
)

J’ai fait ça de tête donc y’a p’têt une p’tite erreur mais l’idée est là…

[R3dKap]

Nickel… Alors quelques questions sur l’organisation de tes données d’abord…

Dans ta liste Produits tu as déjà des colonnes Ref interne, Ref fournisseur, Emplacement, etc. Alors pourquoi les répéter dans la table des Mouvements ? Normalement, une donnée ne dois figurer qu’à un seul endroit (sauf raison valable).

Donc dans ta liste Mouvements tu ne devrais avoir que la colonne de recherche Pièce/produit qui pointe vers ta liste Produits (et les autres colonnes propres au mouvement bien sûr). A toi dans l’application d’aller chercher des informations complémentaires au produit si nécessaire lorsque tu es sur un écran de mouvement (voir plus bas).

Du coup j’en viens à l’écran Saisie de mouvement : pourquoi saisir sur cet écran la Ref fournisseur puisqu’elle est censée être fixe et renseignée justement dans la table Produits ? Idem pour Ref obsolète (et peut-être d’autres que l’on ne voit pas sur ta capture).

Concrètement, tu devrais avoir :

• LISTES
  • Produits
    • Pièce
    • Description
    • Réf. interne
    • Réf. fournisseur
    • Fournisseur
    • Emplacement
    • Qté en stock
    • Seuil d’alerte
    • Réf. obsolète
    • Image
    • Date de mouvement (<– ça c’est pas normal : tu peux pas avoir une date de mouvement ici puisque c’est une caractéristique du mouvement et que tu l’as déjà prévu dans ta liste Mouvements)
    • Catégorie
    • etc.
  • Mouvements
    • Pièce (qui pointe vers la liste Produits)
    • Type de mouvement
    • Quantité
    • Date de mouvement
    • Utilisateur
    • Commentaire
• ECRANS
  • Saisie de produit
    • Tous les champs de ta liste Produits
  • Saisie de mouvement
    • Tous les champs de ta liste Mouvements
    • Si dans ton formulaire tu veux afficher des informations de la pièce sélectionnée pour le mouvement en cours de création/modification, informations qui se trouvent dans la liste Produits, alors ajoute par ex. des libellés dans le datacard du champ Pièce/Produit et alimente-les avec un code du style : LookUp(PRODUITS; ID = DataCardValuePièce.Selected.Id).<nom du champ de la liste PRODUITS que tu veux afficher>
Remplace Produits par le nom de ta liste et DataCardValuePièce par le nom de la liste déroulante Pièce.

Voilà mes recos… 😉

[R3dKap]

Tu peux nous mettre une capture (ou coller) de ton url dans le navigateur quand t’es sur la page blanche ?

[R3dKap]

C’est normal : c’est l’environnement par défaut. Ce qui me fait poser la question de savoir si la récupération de flux supprimés est possible sur l’environnement par défaut. Comme ça au premier abord je dirais que je vois pas pourquoi ce ne serait pas possible… Mais bon, on sait jamais. Evidemment ils ne le précisent pas dans la doc…

Je serais toi je ferais un ticket à MS pour leur demander pourquoi les flux supprimés n’apparaissent pas…

[R3dKap]

Salut @florian,

Mmm… Je vois pas trop comment tu pourrais détecter cette “inactivité”. Je passerais plutôt par de l’information auprès des utilisateurs sur les bonnes pratiques à avoir dans la manière d’utiliser l’application.

[R3dKap]

Top @Nathan, merci pour les captures. Par contre tes 2 premières captures sont identiques. Tu voulais peut-être mettre en première capture cette de ta liste des produits non ?

Si c’est le cas, peux-tu la mettre ici à la suite ?

[R3dKap]

Top merci 👍

Alors… Il y a 2 erreurs sur ton écran : chaque rond rouge/croix blanche représente une erreur -> dès que tu vois une erreur il faut essayer de la corriger pour t’assurer du bon fonctionnement de ton application.

Sur l’erreur de tri tu vois que certaines portions de ta formule sont soulignées en rouge : c’est pour t’indiquer où se trouve l’erreur. En l’occurrence dans ton cas, c’est probablement parce-que le nom de ta colonne “Interlo_DT_Interlo” n’est pas bonne (survole la zone soulignée en rouge pendant 1s sans bouger avec la souris et tu verras le message d’erreur apparaître). De mémoire ici il faut le nom technique de la colonne.

Ton modèle de données est dans SharePoint dans le Dataverse ?

Si c’est SharePoint :

• va dans les paramètres de ta liste
• clique sur la colonne
• récupère le nom technique de ta colonne tout à la fin de l’url de ton navigateur (derrière le “…field=<nom_technique_de_ta_colonne>”)

Si c’est Dataverse :

• va sur ta table
• liste les colonnes de ta table
• repère ta colonne et note le nom logique de ta colonne

[R3dKap]

Salut @MarKAR,

Alors j’ai pas encore pratiqué l’utilisation des business units et des équipes D365 dans Dataverse mais voici quand même mon point de vue.

Si tu veux utiliser des business units et des équipes (on parle bien d’objets D365 exploités via le Dataverse) cela implique que l’entreprise s’est organisée (ou va s’organiser) pour définir toute sa structure via ces objets ; mais surtout il faudra qu’ils soient maintenus à jour -> il faut donc établir une gouvernance claire pour la mise à jour de ces données

Perso, j’aime les solutions simples et efficaces . Sur une grosse application Power Apps je m’étais “contenté” d’utiliser des équipes Dataverse et des rôles de sécurité : des équipes (dans lesquelles je mettais les bonnes personnes) et des rôles customs associés à chaque équipe.

Mais ce n’est que mon humble avis

NOTE : les équipes Dataverse (+ les rôles) servent à identifier le rôle (dans la vie réelle) et donc les droits d’un utilisateur dans l’application (du moins c’est comme ça que je les avais utilisés). Mais selon moi cela ne t’empêche pas de devoir indiquer dans tes tables les chefs et les responsables (voir ci-dessous).

Pour ce qui est donc du modèle de données j’identifie (de ce que j’ai compris) :

• Une table REGIONS
  • Chef de région
• Une table USINES
  • Région (lien vers REGIONS)
  • Chef d’usine
  • Responsable d’usine
• Une table TICKETS
  • Usine (lien vers USINES)
  • Validation région
• Une table TICKETS – VALIDATIONS USINES
  • Ticket (lien vers TICKETS)
  • Usine (lien vers USINES)
  • Validé (oui/non)

Je préfère une table TICKETS – VALIDATIONS USINES plutôt qu’une relation N-N “Validations usines” entre TICKETS et USINES parce-que j’ai plus facilement la main sur son contenu. Les relations N-N créent des tables masquées qui sont un peu relou (je trouve) à manipuler.

Mais tout ça reste à creuser selon le besoin réel…

• Cette réponse a été modifiée Il y a 3 mois par  R3dKap.