Comment identifier les apps #80

Closed
opened 2024-03-09 11:39:32 +01:00 by tonitch · 4 comments
Owner

Nous n'avons pas fait d'endpoints pour les différentes apps.

J'en ai déjà parlé et si on est tous d'accords j'en ferais un jdb mais en gros voiçi ma vision de la chose...

Chaques roles a une liste d'app accésible. Un utilisateurs peut demander la liste qui lui est attribué en fesant une requetes au backend GET /apps-> list.
Le front s'occupe alors de prendre cette liste, de l'afficher et "voilà"

Plusieurs questions se posent pour ça du coup:

  • Avons nous besoin d'applications spécifiques aux utilisateurs ?
    • Si non, on peut "hardcoder les apps dans le backend selon le role de l'utilisateur qui le demande"
    • Si oui, il faudrait stocker les apps par utilisateurs dans la db
  • Quel est le format d'une app.
    • Ma proposition est: {name: str; icon: url}. et le backend enverait une liste de ces éléments. Le frontend implémente alors une page name.vue par apps qui sera loadé dynamiquement en fonction de la liste reçue.
  • Avons nous besoin d'un ordre ?
    • Si oui il faut ajouter l'ordre dans la proposition ci-dessus

Je pense également que pour évider une mauvaise utilisation du site, il faudrait que lorsqu'un utilisateur aille sur la page par example ´/registerRequests´ qu'une requette soit faite sur GET /apps/registerRequests et que le backend retourne un boolean pour savoir si l'utilisateur à accés à cette page (ça n'est pas une sécurité mais une aisance d'utilisation pour éviter de faire des requettes non nécéssaires et de rediriger l'utilisateur correctement en cas d'érreur)

Je sais pas si c'est très clair mais ça serait bien d'avoir ça en place

Nous n'avons pas fait d'endpoints pour les différentes apps. J'en ai déjà parlé et si on est tous d'accords j'en ferais un jdb mais en gros voiçi ma vision de la chose... Chaques roles a une liste d'app accésible. Un utilisateurs peut demander la liste qui lui est attribué en fesant une requetes au backend `GET /apps`-> list. Le front s'occupe alors de prendre cette liste, de l'afficher et "voilà" Plusieurs questions se posent pour ça du coup: - Avons nous besoin d'applications spécifiques aux utilisateurs ? - Si non, on peut "hardcoder les apps dans le backend selon le role de l'utilisateur qui le demande" - Si oui, il faudrait stocker les apps par utilisateurs dans la db - Quel est le format d'une app. - Ma proposition est: {name: str; icon: url}. et le backend enverait une liste de ces éléments. Le frontend implémente alors une page `name.vue` par apps qui sera loadé dynamiquement en fonction de la liste reçue. - Avons nous besoin d'un ordre ? - Si oui il faut ajouter l'ordre dans la proposition ci-dessus Je pense également que pour évider une mauvaise utilisation du site, il faudrait que lorsqu'un utilisateur aille sur la page par example ´/registerRequests´ qu'une requette soit faite sur `GET /apps/registerRequests` et que le backend retourne un boolean pour savoir si l'utilisateur à accés à cette page (ça n'est pas une sécurité mais une aisance d'utilisation pour éviter de faire des requettes non nécéssaires et de rediriger l'utilisateur correctement en cas d'érreur) Je sais pas si c'est très clair mais ça serait bien d'avoir ça en place
tonitch added the
Question
label 2024-03-09 11:39:32 +01:00
Owner

dans mes souvenirs william avait oui un moyen de sauvegarder les settings de l'affichage de sont horaire mais jsp exactement comment il faisait ça (de mémoire dans une DB externe donc on partirai vers le HARDCODAGE du backend)

Format ta propal me semble bien

ordre jsp je comprends pas

l'intérêt ? dans tout les cas si on hardcode les accès en fct du token on fait qu'une requete

dans mes souvenirs william avait oui un moyen de sauvegarder les settings de l'affichage de sont horaire mais jsp exactement comment il faisait ça (de mémoire dans une DB externe donc on partirai vers le HARDCODAGE du backend) Format ta propal me semble bien ordre jsp je comprends pas l'intérêt ? dans tout les cas si on hardcode les accès en fct du token on fait qu'une requete
Author
Owner

ordre = l'ordre dans la liste à gauche. genre je veux que l'horaire soit le premier, ...

et pour le /apps/registerRequests ça permet de dire au front si il doit loader une page ou non. à ce moment il n'a pas fait de requettes de liste parçe qu'il en a pas encore eu besoin

ordre = l'ordre dans la liste à gauche. genre je veux que l'horaire soit le premier, ... et pour le /apps/registerRequests ça permet de dire au front si il doit loader une page ou non. à ce moment il n'a pas fait de requettes de liste parçe qu'il en a pas encore eu besoin
Owner

En vrai j'ai pas l'impression que ca soit obligatoire de faire des applications par utilisateurs vu que en soi on est pas vraiment sur une plateforme de divertissement donc ce que va vouloir faire un utilisateur en venant sur la plateforme dépend en grande partie de son role, cependant, ca pourrait être utile de faire ca pour pouvoir par exemple stocker les applications favorites d'un utilisateur (ce qui rejoint un peu la notion d'ordre que tu donnes on le mettrait en évidence) mais cette feature est pas nécessaire du tout. J'avoues que je ne sais pas vraiment ce qui est le mieux la dedans on pourrait aller vers la simplicité et stocker une liste d'apps liée a chaque roles dans une table (faire ca ne nous ferme donc pas les portes pour le faire aussi par user plus tard si nécessaire)?

En vrai j'ai pas l'impression que ca soit obligatoire de faire des applications par utilisateurs vu que en soi on est pas vraiment sur une plateforme de divertissement donc ce que va vouloir faire un utilisateur en venant sur la plateforme dépend en grande partie de son role, cependant, ca pourrait être utile de faire ca pour pouvoir par exemple stocker les applications favorites d'un utilisateur (ce qui rejoint un peu la notion d'ordre que tu donnes on le mettrait en évidence) mais cette feature est pas nécessaire du tout. J'avoues que je ne sais pas vraiment ce qui est le mieux la dedans on pourrait aller vers la simplicité et stocker une liste d'apps liée a chaque roles dans une table (faire ca ne nous ferme donc pas les portes pour le faire aussi par user plus tard si nécessaire)?
Author
Owner

Je suis d'accord, c'est pas nécéssaire mais on en avait parlé donc c'est pour voir. pour moi le fait qu'elles soients hard-codé c'est bon

Je suis d'accord, c'est pas nécéssaire mais on en avait parlé donc c'est pour voir. pour moi le fait qu'elles soients hard-codé c'est bon
Sign in to join this conversation.
No Milestone
No project
No Assignees
3 Participants
Notifications
Due Date
The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: PGL/Clyde#80
No description provided.