[R3dKap]

Salut @Marine, non je suis pas sûr d’avoir bien compris.

1. Tu veux que certains champs soient masqués sur ton formulaire mais lorsque tu édites un éléments tu veux pouvoir renseigner ces mêmes champs ?!?
2. Est-ce que tu veux que certains champs soient masqués lorsque le formulaire est ouvert en mode affichage et que ces mêmes champs apparaissent lorsque le formulaire est en mode édition ou création ?
3. Je suppose que ton problème n’a rien à avoir avec les vues. Les vues et les formulaires n’ont rien à voir. C’est deux choses distinctes.

CommentID=2arEYredLRSEPgc, PostID=zHcwon71CWQSnaa

[R3dKap]

@Loïc Cimon top composant. Bien foutu et look sympa… J’❤… 😉

Je l’ai testé et j’aimerais échanger avec toi sur 2 ou 3 points… 🙂

1. J’ai pas tout de suite compris qu’il s’agissait d’une application à ouvrir. Comme j’ai vu l’extension .MSAPP je me suis dit que c’était un composant et j’ai donc tenté de l’importer en tant que tel mais évidemment ça ne fonctionnait pas. Peut-être ça serait pas mal sur ton Github de proposer à la fois l’app de test avec le composant dedans, mais aussi juste le composant tout seul pour qu’un développeur puisse simplement l’importer dans son appli.
2. Y’a une fonctionnalité que je pensais trouver sur ton composant que j’aurais trouvé sympa, c’est la sélection d’une période entre 2 dates (un peu comme quand tu réserves un billet A/R pour un train ou un avion). A voir si compliqué à réaliser. On pourrait regarder ensemble si ça te tente…
3. Lorsqu’on ouvre ton application il demande des autorisation pour les connecteurs Outlook et Office 365 Users. Comme tu ne les utilises pas pour le composant (ils devaient traîner là de tests précédent je suppose), il faudrait les enlever pour éviter la popup à l’ouverture de l’app ou à l’import du composant dans son appli perso. Du coup faudra que tu republies et que tu mettes à jour ton Github…
4. J’ai remarqué que tu avais des warnings dans ton composant à cause de l’utilisation de collections et je me suis demandé pourquoi il y avait un paramètre de sortie ComponentId. Et puis j’ai compris que c’était justement à cause de la collection qui est globale et que donc tu dois différencier les dates sélectionnées selon l’instance du composant. Je me demande s’il n’y aurait pas une solution de contournement à ce problème (auquel moi-même j’avais déjà été confronté) en utilisant une chaîne de caractères avec séparateur : “Date1;Date2;Date3;…“. Et le Split() te permettrait de transformer ça en tableau. Plus de collection, plus de warning, plus de ComponentId. J’ai fait un test de mon côté et ça fonctionne. Je te mets la petite app en pièce jointe (à ouvrir en tant qu’application)…

N’hésite pas à challenger tout ça… 😉

CommentID=JFSwhSCKKDNI1S0, PostID=9m4Oew0e9OLlBad

[R3dKap]

@Loïc Cimon

1. Alors oui, ça doit venir du fait que tu l’as exporté depuis une bibliothèque. Mais c’est bizarre quand même parce-que quand je l’ouvre en tant qu’application il me ramène même tes écrans de test et de démo. Si c’était un vrai export de composant il ne devrait y avoir QUE le composant dans le MSAPP. Et encore une fois, je n’ai pas réussi à importer ton fichier en tant que composant. Ce que je fais moi habituellement, c’est que j’ai une app par composant. Comme ça je l’exporte depuis l’app et il n’y a que le composant dans l’export (c’est en attendant qu’ils nous laissent la possibilité de sélectionner les composants à exporter).
2. /
3. /
4. De mon point de vue l’utilisation du scope étendu dans les composants doit être réservé à des cas bien précis. Parce-que cela rend les données de ton app accessibles à ton composant, mais aussi vice-versa (comme lors de l’utilisation de collections dans un composant qui est global et donc visible en dehors du composant, ce qui n’est pas souhaitable -> d’où le warning). A mon avis, la notion même de composant implique que c’est une boîte noire pour l’application et que le seul moyen de faire transiter des données entre l’appli et le composant ce sont les paramètres. Maintenant, franchement, je pense que le boulot est pas si énorme que ça pour convertir ton composant en “mode string” pour éliminer les collections. Je jetterais un oeil un de ces 4 et te donnerai mon avis si tu veux…

SubCommentID=Q8EOEi5WcEwShs7, CommentID=JFSwhSCKKDNI1S0, PostID=9m4Oew0e9OLlBad

[R3dKap]

Salut @aurelien page,

De base ton besoin me semble bizarre… Est-ce qu’on peut creuser un peu ?

Je suppose que tu es en train de faire une app Power Apps qui utilise un fichier Excel comme source de données. Si c’est le cas, il faut savoir que cette solution est à réserver pour des applications persos uniquement, c’est à dire qui ne nécessitent pas l’intervention en simultané (ou pas d’ailleurs) de plusieurs utilisateurs. Car ton fichier Excel doit se trouver sur un OneDrive Business qui est personnel et même s’il est possible de partager un fichier Excel avec d’autres personnes, tu t’embarques dans un truc assez instable. Ce n’est vraiment pas recommandé.

En règle général, si les données sont accédées par plusieurs utilisateurs, on privilégie la création d’une liste SharePoint.

Autre point à étudier : est-ce que ton fichier Excel n’est accédé QUE par le biais de ton app Power Apps ? Si c’est le cas, est-ce que tu ne pourrais pas déporter les formules de ton tableau vers ton app Power Apps. C’est à dire que ce serait ton app Power Apps qui ferait les calculs pour ensuite n’envoyer que des valeurs brutes à ton tableau Excel. Du coup à règlerait ton souci et tu n’aurais plus besoin du script de recopie de ton tableau…

CommentID=e0WPmJc0sFjQu5A, PostID=OH7wUVOExGMHGLk

[R3dKap]

@Theophile CHIN-NIN voir son post précédent :

@Thika n’hésite pas à continuer à poser tes questions dans le même post d’origine pour que l’ensemble des informations soient rassemblées au même endroit… 😉

Sinon, sans vouloir absolument te faire changer d’avis, mais je trouve vraiment la solution du timer beaucoup plus compliqué que simplement le bout de code que j’avais proposé… mais bon… 😉 Y’à qu’à voir la réaction de @Theophile CHIN-NIN d’ailleurs… 😊

Pour ce qui est d’exclure les samedis, dimanches et jours fériés, effectivement il te faut créer une table des jours fériés. Ensuite, l’idée de base n’est pas de supprimer les enregistrements que tu aurais créés en trop mais plutôt de faire le travail en amont, dans le Timer1, au moment de la construction de la liste des dates qui va servir au Timer2.

C’est à dire que dans le OnTimerEnd de Timer1, il faudrait que tu écrives quelque chose comme ceci :

Set(n    newDate; n    DateAdd(n        DataCardValue5.SelectedDate;n        var;n        Daysn    )n);;nIf(n    WeekDay(// Exclusion du dimanchen        newDate;n        StartOfWeek.Sundayn    ) <> 1 &&n    WeekDay(// Exclusion du samedin        newDate;n        StartOfWeek.Sundayn    ) <> 7 &&n    IsBlank(// Exclusion des jours fériésn        LookUp(n            JoursFériés;n            DateJourFérié = newDaten        )n    );n    Collect(n        colDates;n        {n            date: newDaten        }n    )n);;nSet(var;var+1);;n

JourFériés c’est ta liste des jours fériés dans laquelle tu as une colonne DateJourFérié qui contient la date du jour férié.

Voilà, n’hésite pas si tu coinces sur quelque chose…

CommentID=gTLjFbVtZvEkITJ, PostID=PGGF2dlzyKLdZ63

[R3dKap]

Salut @Vincent HERY,

Assez facile à faire :

• tu crées ta liste SharePoint avec une colonne de type Personne et d’autres colonnes à côté qui récupèreront les détails de l’utilisateur
• tu crées un flow qui se déclenche à la création d’un nouvel élément dans la liste :
• le flow utilise le connecteur Azure AD pour récupérer les caractéristiques de l’utilisateur
• puis il met à jour l’élément de la liste avec les détails de l’utilisateur récupérés précédemment

C’est bien ça que tu voulais faire ?

CommentID=AcTtGjMBw7N9O09, PostID=to6HhjFMgSCmdxv

[R3dKap]

@Vincent HERY à ce moment-là, crée plutôt un flow répétitif, qui se déclenche par exemple toutes les heures et qui balaye ta liste pour mettre à jour les propriétés des utilisateurs qu’il y trouvera… Car il n’existe pas de déclencheur sur le connecteur Azure AD…

SubCommentID=QFaGMacsnFNlmH8, CommentID=AcTtGjMBw7N9O09, PostID=to6HhjFMgSCmdxv

[R3dKap]

@Thika pardon je me suis trompé d’emplacement pour le +1 :

DateDiff(DatePickerDebut_1.SelectedDate;DatePickerFin_1.SelectedDate)+1;0;1);"Date";n

SubCommentID=7ck0aNYtG32n7Z3, CommentID=D49VMrVm3p9mWkf, PostID=PGGF2dlzyKLdZ63

[R3dKap]

@Thika s’il ne fait jamais le dernier jour, alors il faut juste rajouter un “+1” juste après la parenthèse fermante du DateDiff() :

DateDiff(DatePickerDebut_1.SelectedDate;DatePickerFin_1.SelectedDate);0;1)+1;"Date";n

Et c’est normal que les jours fériés ne marchent pas. Le tiret “-” est le séparateur des dates au format américain. C’est le slash “/” qui doit être utilisé pour les dates françaises. Mais malgré cela, je ne suis pas sûr que le ClearCollect() que tu fais avec des chaînes (dates entre des guillements) te crée vraiment des dates au final dans ta collection :

ClearCollect(n    colHolidays;n    Split(n        "25-12-2021,27-12-2021,31-12-2021,01-01-2022, 03-01-20222";n        ","n    )n)n

Du coup 2 solutions…

1) Tu remplaces les “-” par des “/” dans ton code ci-dessus et il faut que tu modifies ta condition sur les jours fériés comme ceci :

&& !(Text(Date, DateTimeFormat.ShortDate, "fr-FR") in colHolidays.Result)n

2) Tu modifies la manière dont tu remplis ta collection colHolidays pour y mettre de vraies dates comme ceci (et du coup rien d’autre à changer) :

ClearCollect(n    colHolidays;n    DateValue("25/12/2021", "fr-FR"),n    DateValue("27/12/2021", "fr-FR"),n    DateValue("31/12/2021", "fr-FR"),n    DateValue("01/01/2022", "fr-FR"),n    DateValue("03/01/2022", "fr-FR")n)n

Y’a sûrement moyen de faire plus élégant ou plus optimisé, mais ça ça devrait déjà marcher… 😊

SubCommentID=z3w17I7weBnKx9s, CommentID=D49VMrVm3p9mWkf, PostID=PGGF2dlzyKLdZ63

[R3dKap]

@Thika, du coup, à la suite du code ci-dessus (attention je l’ai modifié récemment, prends bien la dernière version en rafraîchissant la page), tu devrais avoir le code suivant pour boucler la boucle :

Clear(colGestionList);;nForAll(n    colDaysBewteenDates;n    Collect(n        colGestionList;n        Defaults(GestionList)n    );;n    Update(n        colGestionList;n        Last(colGestionList);n        {n            Staff: ComboBoxNom.Selected;n            Assiduite:  ComboBoxAssiduite.Selected;         n            DateP: Daten        }n    )n);;nPatch(GestionList; colGestionList);;n

SubCommentID=hIPQROx25udT5ks, CommentID=D49VMrVm3p9mWkf, PostID=PGGF2dlzyKLdZ63

[R3dKap]

Salut @Thika ,

Voici le code corrigé auquel j’ai rajouté un DropColumns() pour retirer la colonne Value qui a servi à générer les dates :

ClearCollect(n    colDaysBetweenDates,n    DropColumns(n        Filter(n            AddColumns(n                Sequence(n                    DateDiff(n                        DatePickerDebut.SelectedDate;n                        DatePickerFin.SelectedDaten                    );n                    0;n                    1n                );n                "Date";n                DateAdd(n                    DatePickerDebut.SelectedDate;n                    Valuen                )n            );n            Weekday(n                Date;n                StartOfWeek.Mondayn            ) <> 6 && Weekday(n                Date;n                StartOfWeek.Mondayn            ) <> 7 && !(Date in JoursFériés.DateJourFérié)n        ),n        "Value"n    )n)n

Voici ce que ça donne :

@Thika : autre chose… si jamais tu as des erreurs dans une formule, pour nous aider à mieux la pister fait une capture de l’erreur avec la souris qui survole l’erreur (à l’endroit où c’est souligné en rouge plus foncé), comme ceci :

SubCommentID=h1tq2ufcwoj0Atq, CommentID=D49VMrVm3p9mWkf, PostID=PGGF2dlzyKLdZ63

[R3dKap]

Effectivement, je ne le savais pas mais tu peux déclencher le script d’un fichier Excel depuis Power Automate :

SubCommentID=P2dW8WaXPXd4tov, CommentID=sw62zSFotNFXtyI, PostID=OH7wUVOExGMHGLk

[R3dKap]

Ok, je vois. Et t’aurais quoi comme volume ?

Et tu stockerais ces données où ? SharePoint ?

SubCommentID=RgyoNWgBmKUy8kp, CommentID=UnAK1rctoRaMZ2o, PostID=4BxZK1snba2M2pC

[R3dKap]

@Tanguy Touzard NAV ? T’envisages quoi pour le stockage des données ? En gros l’appli fait quoi ?

Pour les PJ, ce que tu peux faire c’est de mettre tes docs dans une bib SharePoint par ex., puis de la mettre en source de données dans l’appli Powe Apps et proposer des liens qui mènent directement aux docs. En cliquant dessus, quand t’es sur un mobile, je crois qu’il te propose de le télécharger : charge à l’utilisateur de le mettre où bon lui semble pour le retrouver plus tard.

Mais tu ne peux pas à partir de Power Apps spécifier un emplacement d’enregistrement d’un document que t’aurais éventuellement pré-chargé via un flow…

SubCommentID=UFyWm5QAKTHYuyy, CommentID=UnAK1rctoRaMZ2o, PostID=4BxZK1snba2M2pC

[R3dKap]

@Tanguy Touzard j’ai oublié de parler de la synchro.

Et avant ça, une petite précision : dans la gestion des données de l’application, je fais la différence entre ce que j’appelle le référentiel et les données applicatives :

• Référentiel : liste de valeurs qui servent principalement dans des lookups, ou listes de paramétrage, etc. (par ex. une liste des véhicules de location de l’entreprise, ou une liste de bouquins à louer, etc.). Ces données ne sont pas modifiées par les utilisateurs mais plutôt par les admins.
• Données applicatives : ces données sont celles qui sont manipulées par les utilisateurs finaux (par ex. : les locations des véhicules par les salariés, ou les emprunts de bouquins, etc.).

Revenons sur la synchro…

La synchro a 2 raisons d’être :

1. T’as des données stockées dans le cache local lorsque tu étais en mode déconnecté et tu ne les as pas encore poussées vers tes sources de données.
2. T’as des utilisateurs qui peuvent aussi modifier les données côté backend et il faut donc les pousser vers l’application pour qu’elle en aie connaissance.

L’idéal c’est évidemment d’éviter le point 2 😉 et de faire en sorte que tes données ne puissent être modifiées que par le biais de l’application. Ca évite de faire une synchro avec gestion des conflits où tu finis par redévelopper l’algorithme de OneDrive 😁.

En gros y’a 3 solutions pour réaliser la synchro :

• soit ton appli synchronise les données dès l’ouverture : toutes les données du cache local non encore sauvegardées sont poussées vers tes sources de données puis tous les référentiels de tes sources de données sont mis à jour dans le cache local ;
• soit ton appli effectue cette synchro à intervalle régulier “en tâche de fond” à l’aide d’un timer (toutes les 2mn par ex.)
• soit la synchro est déclenchée manuellement par l’utilisateur : l’avantage c’est qu’il peut choisir ce qu’il pousse ou pas côté sources de données (c’est que j’avais fait dans mon appli).

Et pour finir j’ai oublié de préciser aussi que j’ai ouï dire que les applications model-driven intègrent automatiquement un mode déconnecté. A creuser…

SubCommentID=vLRQU5SFtn7jkE7, CommentID=UnAK1rctoRaMZ2o, PostID=4BxZK1snba2M2pC