Browse items (or fragments) from personal viewpoints
Description
What is the valuable outcome that cannot be achieved with current features?
For which stakeholder (people, role, project, domain) is it important?
Which user action should be enabled (or restricted)? For who?
Additional details (solutions you think about, or workarounds you tried)
Deliverables status
Phase 1
- [ ] Scenarios (Gherkin)
- [ ] Mockups
- [ ] Implementation strategy
Phase 2
- [ ] Acceptance tests (Capybara)
- [ ] Implementation
Phase 3
- [ ] Screencast
For the "Study abroad" project . It would be interesting for the user to be able to create personal viewpoints (e.g. favorites) and to be able to consult them.
@lerideew Indeed. Is she the only one interested in her own favorites? Or would it be interesting for her to share her favorites so someone else can browse them?
@benel In that case it would be interesting for other students to be able to consult others personal viewpoints. It would allow users to see connections between UEs that they didn't think of or to look at similar UEs because of something else than their attributes for example.
@lerideew Other students, OK... Anyone else that could be interested in this (structured) choice of courses?
For the Greek vases projects. I think it may be helpful for a user to consult items according to personal viewpoints if these constitute the research work of the user.
@benel Of course it would be useful for most users, it was only an example. The RI team can create "structured choice of courses" and can be interested to see the students viewpoints, same thing for the RRIP
Pour Collectives' stories, cela permettrait aux utilisateurs de se fabriquer leur propre choix d'articles, d'expériences qui les intéressent. A la manière de Pinterest, avoir son propre tableau (viewpoint ici) qu'il serait possible de partager et de consulter.
Scénario + Maquette ticket 51
LE SCENARIO #language: fr
Fonctionnalité: Parcourir des éléments (ou fragments) à partir de points de vue personnels
Scénario: Soit "Partage de récit" le portfolio ouvert Et l'utilisateur "alice" connecté Quand l'utilisateur choisit "Favoris" comme point de vue Alors le point de vue "Favoris" est sélectionné Et l'item "Culture de carottes" est affiché Et l'item "Didier Raoult et la Chloroquine" est affiché Et l'item "Création d'un site web pour un village" est affiché
LES MAQUETTES

Pour Partage de récits d'expérience, je propose cette stratégie d'implémentation pour le ticket 51 :
-
Partie du code impactée : . src/components/Authenticated.jsx ----> classe Authenticated : ajout d'une méthode de récupération des viewpoints de l'utilisateur connecté . src/components/portfolioPage/ViewpointCreator.jsx ----> méthode render : ajout d'un bouton (pour l'ajout du pdv perso) . src/components/portfolioPage/Portfolio.jsx ----> méthode _fetchAll() : La méthode doit, en plus des points de vue récupérés par la requête sur l'utilisateur par défaut, retourner les points de vue de l'utilisateur connecté (s'il y en a un)
-
Il faut exécuter une nouvelle requête pour récupérer les points de vue de l'utilisateur : GET /user/UtilisateurConnecté, puis filtrer le résultat de la requête afin d'obtenir la liste des points de vue.
classe Authenticated : ajout d'une méthode de récupération des viewpoints de l'utilisateur connecté
Je crains que ça ne soit pas très bon pour l'independance des modules...
Je n'ai pas réfléchi plus que ça au problème mais je dirais que la seule chose qu'il semble raisonnable de faire remonter aux composants qui le contiennent ce serait l'identifiant de l'utilisateur.
La récupération du portfolio de l'utilisateur se ferait alors au même niveau que celle du portfolio officiel. Vu la manière dont est conçue la bibliothèque hypertopic et en particulier la méthode getView (chaque paramètre pouvant être un tableau d'URI, en étant un peu astucieux vous devez pouvoir mutualiser complètement le code existant !
Après moultes débats, on pense avoir trouver quelque chose de correct 👍 Nous voulons faire en sorte que l'utilisateur a accès à un deuxième portfolio (identique au premier - nommé vitraux ici mais où il pourra ajouter/supprimer ces points de vues, nommé vitraux-personnel). Nous pensons à :
- créer un bouton "Portfolio personnel/global" sur le Header qui, avec la méthode onClick(), nous permettra de déclencher un changement d'état entre vue vitraux et vue vitraux-personnel (géré dans index.js ou alors juste en changeant la valeur de l'attribut "user" de conf.yml) ;
- il faut gérer le fait que l'utilisateur doit être connecté pour avoir accès à se bouton, peut être à la manière du texte "Se déconnecter" de Authenticated.jsx qui ne s'affiche que quand l'utilisateur est connecté. (faire un fetchsession ?)
- il nous faut permettre à l'utilisateur de créer/supprimer les points de vue lié à vitraux-personnel. Doit-on créer du coup dans la db une copie du 1er portfolio vitraux et l'appeler vitraux-personnel et faire des requêtes POST pour ajouter des points de vues sur vitraux-personnel, ou faut-il attacher ces nouveaux points de vue à vitraux et les "taguer" comme appartenant a l'utilisateur ?
- Connaître le login de l'utilisateur connecté nous serait judicieux. Comment peut-on le récupérer
- Il faut gérer le fait de revenir au portofolio vitraux quand l'utilisateur se déconnecte, même s'il n'est pas revenu sur la page vitraux. rajouter un événement dans le handlelogout() de la classe authenticated.jsx qui aura un comportement similaire au bouton "portofoliopersonnel/global"
Après moultes débats, on pense avoir trouver quelque chose de correct 👍 Nous voulons faire en sorte que l'utilisateur a accès à un deuxième portfolio (identique au premier - nommé vitraux ici mais où il pourra ajouter/supprimer ces points de vues, nommé vitraux-personnel).
Oui c'est un peu une variante du clonage de portfolio (#190). Par rapport, à ce clonage, vous évitez le problème de CORS d'un nouveau site... Par contre, ça pose pas mal de questions d'interface (et d'adaptation au modèle). Mais bon la piste est intéressante, je ne veux pas vous brider. On discutera de tous ces détails quand vous aurez des maquettes.
@Hypertopic/partage-de-recits-d-experience
Idem par rapport à ma colonne "Being integrated and deployed".
Merci de faire le point sur les sous-livrables terminés et de m'indiquer quelles cases je dois cocher.
Si les 5 sont cochées et qu'il y a une pull request validée, à ce moment là j'accepterai effectivement le ticket dans ma colonne. En attendant, elle devrait être dans In design & development. Merci d'avance.
Nous avons 2 questions :
- nous aimerions passer d'une page portofolio a une autre avec un bouton "portofolio suivant". Nous avons implémenté le bouton mais nous n'arrivons pas à changer la vue (le mieux que l'on arrive à faire est de mettre les deux vues portofolio à la suite sur la page web). Avez-vous une idée de comment faire ?
- nous aurions besoin d'attacher au point de vue personnel au login de la personne connecté. Pouvons nous récupérer ce login via une requête sur la bdd à la manière des requêtes sur les items ? Pouvons-nous ajouter un attribut sur l'objet point de vue type "login associé" ou il sera null s'ils 'agit du portofolio public, et il aura la valeur du login de la personne connecté s'il s'agit de son portfolio personnel ?
Maquette ticket 51

Nous avons 2 questions :
- nous aimerions passer d'une page portofolio a une autre avec un bouton "portofolio suivant". Nous avons implémenté le bouton mais nous n'arrivons pas à changer la vue (le mieux que l'on arrive à faire est de mettre les deux vues portofolio à la suite sur la page web). Avez-vous une idée de comment faire ?
Pour pouvoir alterner entre 2 page, on a eu plusieurs solution après avoir fait des recherches:
- La première est de le faire dans index.js au niveau du router et ajoute un route path pour la nouvelle page.
-La deuxieme est d'utiliser Link from 'react-router-dom/modules/Link'.
Le problème est qu'on arrive pas à a faire un Link to={un component} et on a cette erreur:
Pouvez vous nous aider pour trouver une solution?
Bonjour @Erilysse,
Je vais essayer de répondre à vos questions... mais ça me semble quand même perilleux de vous lancer dans cette fonctionnalité dans la dernière semaine, alors que j'ai l'impression que rien n'est très clair ni pour les maquettes, ni pour les scénarios ni pour la stratégie de développement....
Bonjour @benel ,
Nous avons rencontré de grandes difficultés sur nos tickets, et nous nous sommes pas mal éparpillés (nous avons tenté de faire la conception de 4 tickets, pour nous rendre compte que le #184 et #185 étaient extremement compliqué à mettre en place -> personnellement, je n'ai jamais réussi à mettre en place le serveur SMTP du tutoriel que vous nous aviez gentiment donné. ) Nous nous retrouvons donc alors avec une seule fonctionnalité prête pour la fin du semestre. Nous pensons donc qu'entre les 3 restantes, le #51 est la plus à même d'être fini ou du moins bien avancé pour rendre quelque chose de correcte.
Pour le projet 'EUT+" nous pensons qu'il serait intéressant de consulter les profil des autres étudiants afin de voir leurs UE/compétences suivies.