[DavidZed]

Dans, ce cas, le plus simple est de créer une colonne lookup / recherche dans ta table membre, qui pointe vers la table genre.

La relation sera créé automatiquement, c’est beaucoup plus simple et pratique pour nommer la colonne en question.

Il n’est obligatoire de passer par la création de relations que pour les relations N:N

• Cette réponse a été modifiée Il y a 9 mois, 3 semaines par  DavidZed.

[DavidZed]

Si tu as la même source de données (même ,collection ou source de données SP, DV etc…), supprimer un enregistrement le fera disparaître des deux galeries.

Si tu as deux sources de données différentes, il faudra faire deux Remove (ou RemoveIf ) :

RemoveIf(
Tableau_Debrief_2J;
Type_Entretien = ThisItem.Type_Entretien) ;;

RemoveIf( Tableau_Debrief_1J; Type_Entretien =ThisItem.Type_Entretien)

Si le bouton de suppression est hors de la Gallery2 il faudra mettre Gallery2.Selected à la place de ThisItem

Un conseil: mieux vaut se baser sur l’ID ou une colonne dont on est sûr qu’elle contient des valeurs uniques dans ce genre d’usage

[DavidZed]

Bonjour,

Le plus simple, je pense, est de trier les données affichées dans la table par date de création, exemple :

Dans la propriété Items de ton contrôle table :

Sort(‘Nom de la source Dataverse’ ; ‘Créé le’ ; SortOrder.Ascending)

[DavidZed]

Hello,

C’est effectivement apparu quand les named formulas ont été annoncées et déployées en fonction experimentale, quasi dans la foulée. Il y a eu quelques exemples donnés pour créer des fonctions personnalisées.

Entre temps, les équipes power apps ont vraisemblablement décidé de nous livrer la fonctionnalité complète en deux fois : named formulas dans un premier temps et user defined functions ensuite.

Le paramètre App.Formulas ayant été développé pour accueillir les user defined functions, il ne génère pas d’erreurs si la syntaxe est respectée.

Le fait que les descriptions et mentions des user defined functions ont disparu des annonces, ne laisse malheureusement pas présager d’une date de sortie proche, même en fonctionnalité expérimentale. Il est même possible que ce soit abandonné.

En attendant, il est possible de créer des fonctions personnalisées grâce aux propriétés avancées des composants, qui devaient arriver en GA avant les user defined functions. C’est d’ailleurs le sujet de la session que nous avions présenté au ppfs avec R3dkap il y a peu : https://www.youtube.com/live/_PmxgslTI30?si=rVUMQHmeDau3AV5e&t=20906

[DavidZed]

Bonjour, c’est le 2eme argument du lookup, donc un test logique qui va déterminer quel enregistrement obtenir grâce à la fonction lookup :

Il indique que le “Title” de ta liste doit être égal au texte affiché dans la “DataCardValue11”, qui doit certainement être un contrôle textinput dans un formulaire.

Si tu as récupéré ce code ailleurs, il te faudra modifier cette partie pour qu’elle fasse référence à des valeurs définies dans ton appli.

[DavidZed]

Hello Charles,

Pour moi il y a deux aspects assez différents à prendre en compte dans ta question :

La dimension partage “d’accès”

Dans le contexte que tu décris, le partage des solutions et des flux sera suffisant dans la majeure partie des situations.

Il n’est pas nécessaire de partager les références de connexion et les variables d’environnement, ces dimensions sont accessibles sans rôle de sécurité particulier.

Le seul point bloquant que tu vas certainement rencontrer, c’est que tu ne pourras pas développer de solutions avec Dataverse, si tu ne peux pas créer ou modifier les rôles de sécurité.

Tu risques également d’être limité dans le déploiement de solutions avec le rôle system customizer, l’idéal est d’avoir un rôle d’admin système (idéalement sur un compte de service dédié, voir ci-après).

La dimension de propriété des éléments de la solution :

Pour que ton client sécurise la propriété de ces développements, il est indispensable que le déploiement des solution, qu’elles soient managées ou non, soit faite à l’aide d’un compte technique / de service / non nominatif (plusieurs dénominations possibles).
Car c’est le compte qui déploie qui sera propriétaire des éléments déployés dans la solution, il est donc important que ce compte ne soit dépendant d’une personne ou de sa présence dans les effectifs de l’entreprise.

Pour moi le déploiement avec un compte nominatif ne doit se faire que pour des projets citizen-dev et dans un environnement qui leur est dédié.

[DavidZed]

Hello,

C’est assez étrange comme bug, tu n’as rien dans la partie configure layout ? Et les colonnes sont bien cochées dans la partie Edit columns ?

Autre paramètre à vérifier dans les paramètres du site > propriétés de la liste > propriétés du formulaire :

[DavidZed]

Hello, dans ton power query sur cette source, vérifie que tu n’as pas coché par mégarde l’option utiliser une passerelle de données

[DavidZed]

Hello,

Le plus simple, sans partir dans du code custom est d’utiliser un formulaire à plusieurs étapes et de mettre les champs image dans la 2eme étape (ou après)

La première étape est en mode créer un enregistrement, les suivantes sont toujours en mode modification d’un enregistrement existant.

[DavidZed]

A l’heure actuelle, l’intégration de power apps for teams dans des canaux partagés n’est pas supportée.

A la place, il est possible de diffuser une appli hors d’une équipe teams avec l’option “Partager avec des collègues” :

Dans cette fenêtre , il est possible de partager une ou plusieurs applis de l’équipe avec un groupe (M365 ou de sécurité)

Les utilisateurs trouveront l’appli directement dans leur magasin teams et pourront l’épingler au volet latéral :

C’est une manière de sécuriser l’accès à la solution, car les seuls les utilisateurs qui sont dans l’équipe pourront accéder directement aux données, tables et modifier l’app.

[DavidZed]

Hello Julien,

A ta place, je partirai sur une collection qui se chargerait au chargement de l’écran sur le OnVisible de cet écran pour alimenter la galerie :

ClearCollect(colGalForms,
{Formulaire_Nom : “Formulaire 1” , Item: LookUp(‘Liste form1′,’Lookup Column’.Value = vctxTitleFormPrincipal.title)},
{Formulaire_Nom : “Formulaire 2” , Item: LookUp(‘Liste form2′,’Lookup Column’.Value = vctxTitleFormPrincipal.title)},
{Formulaire_Nom : “Formulaire 3” , Item: LookUp(‘Liste form1′,’Lookup Column’.Value = vctxTitleFormPrincipal.title)}
)

Je me base ici sur la Value du lookup, car malheureusement, faire la même chose sur l’ID du lookup rendrait les requêtes non délégables, mais cela reste une option si tu es sûr que tes listes contiendront toujours moins de 2000 éléments.

la variable vctxTitleFormPrincipal étant à charger depuis l’écran précédent, dans le navigate()

en mettant la collection colGalForms dans ta galerie, tu pourras conditionner la visibilité de ton icône avec la condition : !IsBlank(Thisitem.Item)

Tu pourras également changer le mode du formulaire en t’inspirant de la solution donnée ici : Composant de changement d’état de formulaire – Power Apps – Power Platform French Community (ppfc.fr)

[DavidZed]

C’est assez logique pourtant, mais cela souligne l’importance du nommage des tables, colonnes etc…

Ici, si tu retrouves ta valeur avec ThisItem.type.type, c’est parce que dans ta table Membre, tu as une colonne lookup qui se nome “type” et qui a la table “Genre” comme source, et que dans la table Genre, tu as une colonne (très certainement de type option/choice) qui se nomme également “type”

Généralement, je nomme les colonnes lookup avec le nom de la table ciblée quand c’est pertinent et que c’est le seul lookup vers cette table, s’il y en a plusieurs, je fais en sorte que le nom de la table figure dans celui de la colonne. Par exemple une colonne lookup vers la table langue :

Si c’est la seule colonne : Langue

S’il y en a plusieurs : Langue maternelle, Langue secondaire, Langue tertiaire etc…

Avec cette règle de nommage, tu aurais ThisItem.Genre.Type pour afficher ta valeur

[DavidZed]

Non, pour les dates, ascending va du plus petit au plus grand, donc du plaus ancien au plus récent

[DavidZed]

Il est clair que le jour où les user defined functions verront le jour, ce sera sensiblement moins lourd en ressources que de passer via les composants, même si, pour avoir pas mal fait de tests, les performances des requêtes sont tout à fait honorables. Mais il y a toujours cette étape de passer par un contrôle (le composant en lui-même) alors qu’une UDF irait directement interroger la source de données.

Pour ce qui est des named formulas à l’heure actuelle, j’y vois tout de même un intérêt, sur deux aspects particulièrement :

• Le fait qu’il s’agisse de constantes toujours à jour, celà simplifie pas mal la remontée d’indicateurs sans avoir besoin de faire des Refresh() ou de mettre à jour une collection, très pratique quand plusieurs utilisateurs d’une appli doivent voir remonter les modifs et ajouts des uns et des autres en temps réél (ou presque)
• J’y mets généralement tout ce que je mettais en variables “fixes” dans le OnStart : Thème couleurs, Tables de menus, Icones SVG… et je trouve que cela se ressent au lancement de l’appli (mais c’est peut-être subjectif 😀 )

[DavidZed]

Au temps pour moi c’est un paramètre qui n’est pas censé apparaître sur une source SP dans Power BI

Si tu ajoutes manuellement la même source dans une autre requête, tu as le même problème ?