Register as a contributor

benel commented 5 years ago

Dangerous feature until #183 is implemented.

Having an e-mail for each account would be better to "trust" corresponding users (and blame them when a problem occurs).

Note: In TraduXio, we already implemented a two steps creation with trusted and untrusted users.

Phase 1

[x] Mockups
[x] Scenarios (Gherkin)
[x] Implementation strategy
Phase 2
[x] Acceptance tests (Capybara)
[x] Implementation

Kodlah commented 4 years ago

Projet Graines d'artistes : Permettre aux utilisateurs de confiance de s'enregistrer sur la plateforme, comme par exemple les jurés.

garnier5 commented 4 years ago

It would be interesting for the "Studing Abroad" project to be able to register in order to create user rights and keep track of each person's activities on the platform.

Rinkichi75 commented 4 years ago

Projet: Partage de récit d'expérience Pour pouvoir notifier, les contributeurs que quelqu'un a commenté son récit.

benel commented 4 years ago

@Rinkichi75 Il n'est pas explicitement question ici de notification (même si effectivement les deux pourraient être liées). Par contre, il y a un autre ticket qui parle de s'abonner à une catégorie... Vu l'usage que vous imaginez, peut-être pourriez-vous créer un ticket pour s'abonner à un item ?

ValentinLouerat commented 4 years ago

Projet : Approche par compétence de la formation Important pour que chaque personne (ou entreprise) puisse donner son avis

MaximeD89 commented 4 years ago

Projet : Visite sur site de vitraux

Ce point est essentiel car dans le ticket :

Authorize a contributor to edit a viewpoint #183

nous permettons à certains utilisateurs de modifier des points de vue.

Il permettra donc de donner une certaine confiance ainsi que des droits à des utilisateurs que l'on qualifiera de "fiable".

ghost commented 4 years ago

Scénario 👍

Scénario: apparition du formulaire Soit la page d'accueil Quand l'utilisateur clique sur "s'enregistrer..." Alors le formulaire d'enregistrement apparaît

Scénario: création du contributeur Soit le formulaire d'enregistrement Quand la valeur de l'attribut "nom d'utilisateur" est "alice" et la valeur de l''attribut "adresse email" est "alice.whiterabbit@gmail.com" et la valeur de l'attribut "mot de passe" est "whiterabbit" et valeur de l'attribut "confirmation du mot de passe" est la valeur de l'attribut "mot de passe" Alors un email de confirmation est envoyé à "alice.whiterabbit@gmail.com" et le compte du contributeur "alice" est créé

Stratégie d'implémentation :

dans la classe Authenticated.js : ajouter un autre état "join", ainsi qu'une méthode handleJoin() ; le render aura une nouvelle boucle if (this.state.join) ==> formulaire d'enregistrement et ajout en bdd via une requête fetch(API POST) du contributeur avec un booléen "confirmed" : false au début) pour l'envoi d'un email de confirmation, s'inspirer de https://blog.bitsrc.io/email-confirmation-with-react-257e5d9de725 et le réutiliser après pour le ticket #185. après que l'utilisateur a cliqué sur le lien envoyé dans l'email de confirmation, requête fetch(API) pour modifier l'état "confirmed" à true.

benel commented 4 years ago

Pour le scénario, essayez de supprimer au maximum les éléments d'interface (ce sont les données qui comptent).

pour l'envoi d'un email de confirmation, s'inspirer de https://blog.bitsrc.io/email-confirmation-with-react-257e5d9de725 et le réutiliser après pour le ticket #185.

Je n'ai pas lu l'article de blog avec attention, mais ça va être compliqué ou risqué de faire envoyer des mails par du JS côté client (où alors vous allez devoir passer par un service tiers qui est possiblement douteux). Je vous recommanderai plutôt de regarder la partie du TP ci-dessous : https://github.com/benel/TP-CouchDB/wiki/Node#adaptateur-inversé-vers-smtp

benel commented 4 years ago

C'est un tout petit programme, à part (sur une machine serveur mais c'est en fait un client du point de vue logiciel), qui écoute CouchDB et qui réagit aux changements de données en se connectant à un serveur SMTP pour envoyer un courriel.

ghost commented 4 years ago

J'ai testé avec le client de faire une requête PUT pour créer un utilisateur comme expliqué dans la documentation https://docs.couchdb.org/en/stable/intro/security.html?highlight=user#creating-a-new-user , sauf que j'ai une erreur : "error":"illegaldocid","reason":"Only reserved document ids may start with underscore." or si j'enlève de _users j'ai une autre erreur qui me demande de m'authentifier. Je pense qu'il faut que je reste sur _users vu qu'il s'agit d'une classe préconfiguré, mais je n'arrive pas à trouver de fil sur internet pour m'aider. (https://stackoverflow.com/questions/3456256/error-creating-user-in-couchdb-1-0 qui parle que il faut forcément être admin, ou alors de purger certains documents ?)

benel commented 4 years ago

Ajoutez dans votre objet JSON :

"_id": "org.couchdb.user:jan"

ghost commented 4 years ago

Ca ne marche toujours pas (même en enlevant du coup l'id de l'url) J'ai l'impression que la table _users n'est pas accessible ? En checkant argos2.test.hypertopic.org directement en pageweb elle n'a pas l'air d'exister ou du moins elle n'apparaît pas si on n'est pas connecté ?

J'ai essayé de faire la requête PUT après avoir faire une requête POST sur _session en tant qu'alice, et ça ne marche toujours pas, j'ai toujours la même erreur. Pouvez-vous tester la même requête en tant qu'administrateur ?

benel commented 4 years ago

C'est probablement un problème de réécriture. Pouvez-vous entrainer sur un CouchDB local ?

Je m'occuperai dans les jours qui viennent de "vous ouvrir la porte" pour que la requête atteigne CouchDB.

Rinkichi75 commented 4 years ago

Bonjour, J'ai voulu créer une page pour creer un compte, pour cela je passe par un button qui onClick() et sensé me redirigé vers la page (Je me suis inspiré de la classe ViewpointCreator) mais je me retrouve avec cette erreur. Savez vous Pourquoi?

benel commented 4 years ago

@Rinkichi75 Ce que vous dit le message d'erreur c'est que this.props.history n'a pas de valeur.

Vérifiez que vous le passez bien en paramètre de votre composant (ici visiblement c'est Authenticated) quand il apparaît dans le composant père comme une sorte d'élément HTML.

benel commented 4 years ago

J'ai l'impression que la table _users n'est pas accessible ?

C'est probablement un problème de réécriture. Pouvez-vous entrainer sur un CouchDB local ? Je m'occuperai dans les jours qui viennent de "vous ouvrir la porte" pour que la requête atteigne CouchDB.

@Erilysse C'est fait : désormais Argos possède l'URI /_users qui permet de créer des comptes CouchDB.

benel commented 4 years ago

@Erilysse N'oubliez pas de faire vos tests sur le serveur de test (et non celui de production). Merci.

ghost commented 4 years ago

Maintenant, j'ai l'erreur "unauthorized". J'ai testé la même requête. test_argostest_notworking

benel commented 4 years ago

Maintenant, j'ai l'erreur "unauthorized". J'ai testé la même requête.

N'oubliez pas de vous authentifier (avec BasicAuth ou par session).

benel commented 4 years ago

Oops, pardon. Je n'avais pas vu que c'était pour '_users'.

benel commented 4 years ago

@Erilysse C'est le proxy qui bloque votre requête...

Je regarderai si je peux modifier le proxy une fois que j'aurais terminé ce que je fais en ce moment (intégration du code d'un de vos camarades).

En attendant vous pouvez vous entraîner sur un CouchDB local...

benel commented 4 years ago

@Erilysse J'ai modifié le code du proxy pour laisser passer la requête https://github.com/Hypertopic/AAAforREST/commit/7ae1f27622e9004314c7100b2f47ca44f9200983

Notez bien que vous devez mettre un "slash" à la fin de cette URI.

benel commented 4 years ago

@Erilysse Ça y est : le nouveau code du proxy est en production sur le serveur de test.

ghost commented 4 years ago

Bonjour, J'ai une nouvelle erreur "error": "unauthorized", "reason": "You are not a server admin." Je pense qu'en vu du rendu qui se profile pour cette fin de semaine, nous allons devoir abandonner cette fonctionnalité. Nous avons tout de même créé le formulaire d'inscription, il s'agit juste de la requête qui bloque j'ai l'impression.

benel commented 4 years ago

Je pense qu'en vu du rendu qui se profile pour cette fin de semaine, nous allons devoir abandonner cette fonctionnalité.

@Erilysse Oui c'est plus sage.

Je pense qu'en vu du rendu qui se profile pour cette fin de semaine, nous allons devoir abandonner cette fonctionnalité. Nous avons tout de même créé le formulaire d'inscription, il s'agit juste de la requête qui bloque j'ai l'impression.

Si ce n'est qu'un problème de configuration, faites quand même la demande d'intégration. Je regarderai quand j'aurai le temps.

lildelfino commented 3 years ago

Graine d'artiste : Permettre aux artiste de s'enregistrer pour soumettre leurs oeuvre, ou les commenter par exemple. cela permettrait également d'accorder des droits différents selon les utilisateurs. Par exemple permettre seulement aux membres du jury de voter.

benel commented 3 years ago

Permettre aux artiste de s'enregistrer pour soumettre leurs oeuvre

@lildelfino @Hypertopic/graines-d-artistes-1
Ça a effectivement du sens.

ou les commenter par exemple.

Notez que les commentaires se font à travers le plugin Disqus.

Comme vous le voyez à l'écran, les comptes à utiliser pour les commentaires sont au choix : un compte Disqus (la fonctionnalité de création de compte est alors déjà intégrée), Facebook, Twitter ou Google.

cela permettrait également d'accorder des droits différents selon les utilisateurs. Par exemple permettre seulement aux membres du jury de voter.

Notez bien qu'en informatique, on sépare habituellement l'authentification ("Qui est-ce ?") et l'autorisation ("Qu'a-t-il le droit de faire ?"). Les verbes correspondants en anglais américains sont "authenticate" et "authorize". Concernant le second, vous devriezpeut-être chercher les tickets qui le mentionnent...

Notez également que les deux verbes sont souvent associés (dans le paradigme dit "des trois A") à un troisième : "Accounting", en français "traçabilité" ("Qui a fait quoi ?"). C'est particulièrement pertinent dans un système participatif (par exemple dans un wiki tout est autorisé pour tout le monde, mais tout est tracé et peut être annulé si nécessaire).

Toine-prog commented 3 years ago

Projet Cité du vitrail (Orienté communication) :

Cette fonctionnalité nous serait utile car elle permettrait aux personnes expérimentées et ayant des connaissances sur les vitraux de s'enregistrer afin de laisser un commentaire qui serait "certifié" et donc fiable. Celui-ci pourrait alors approuvé ou non la véracité des attributs ou description d’un vitrail. Le nom de l’utilisateur “certifié” apparaît alors dans une autre couleur pour le mettre en avant.

benel commented 3 years ago

@Toine-prog @Hypertopic/cite-du-vitrail

Le principe général que vous exposez a effectivement du sens...

Par contre, vous parlez de commentaires, là c'est un peu différent puisque les commentaires sont gérés par un plugin tiers (Disqus) qui a son propre système d'authentification, et d'ailleurs qui a aussi plusieurs statuts d'utilisateurs qui apparaissent effectivement dans les commentaires pour donner plus de poids à certains.

Attention par ailleurs que ce que vous mentionnez (le fait de faire apparaître qu'une information vient de telle personne qui a un statut spécial) est plutôt de l'ordre de la traçabilité. Ce n'est pas inclus dans le fait de se créer un compte (même s'il y a bien sûr un lien).

Pour résumer :

Ce ticket-ci permet de rendre plus facile l'inscription des gens à la plateforme (pour le meilleur mais aussi pour le pire, c'est pour cela que le premier commentaire précise que c'est probablement dangereux de l'implémenter avant que le ticket #183 le soit aussi) ;
Vous faites une proposition intéressante (mais assez ambitieuse, puisqu'il faut changer le modèle de donnée de notre API) qui serait de garder la trace de qui a associé une catégorie à un item. C'est tout à fait pertinent, mais il faut créer un ticket différent.

sarah-ngn commented 3 years ago

Graines d'artistes : Permettrait à un artiste ou à un juré afin de d'accéder à plus de fonctionnalités (ajouter une œuvre par exemple)

benel commented 3 years ago

@sarah-ngn @Hypertopic/graines-d-artistes-1

Les jurés étant en petit nombre, on peut continuer à créer leurs comptes à la main (directement via l'API). Par ailleurs, d'une année sur l'autre, il est probable que ce soient un peu les mêmes.
Par contre, vous avez tout raison concernant les candidats. Leur nombre est très important et ils sont différents tous les ans. Par contre cela pose la question redoutable des autorisations...

Notez que l'envoi des œuvres de manière numérique est intéressant mais représente un changement énorme pour l'association (il devient difficile par exemple d'exposer, de prêter les œuvres, de les conserver). Pas sûr que ce soit dans leurs projets... C'est un sujet intéressant à aborder avec eux. Mais ne soyez pas trop déçus s'ils vous disent que ce n'est pas à l'ordre du jour.

theobour commented 3 years ago

Nous pensons que cette fonctionnalité est intéressante pour le projet Eut+. Du fait que la plateforme doit être accessible par l'ensemble des universités, il faut que l'ensemble des personnes intéressées puissent rejoindre la plateforme en s'enregistrant. Actuellement, il est possible de créer un compte en s'adressant directement au backend gérant l'authentification. Le but de cette fonctionnalité est d'ajouter la création de compte sur le front end, via un formulaire, afin de faciliter cette création par tous les utilisateurs.

benel commented 3 years ago

Actuellement, seul les personnes ayant un compte UTT peuvent accéder à Porphyr.

Pour être tout à fait précis, il est déjà possible de créer un compte mais en s'adressant directement au backend. Pouvez-vous du coup reformuler le gain entre avant et après la mise en production de cette fonctionnalité ?

theobour commented 3 years ago

Actuellement, seul les personnes ayant un compte UTT peuvent accéder à Porphyr.

Pour être tout à fait précis, il est déjà possible de créer un compte mais en s'adressant directement au backend. Pouvez-vous du coup reformuler le gain entre avant et après la mise en production de cette fonctionnalité ?

Je viens de modifier mon commentaire afin de bien faire apparaitre le fait que la création de compte est déjà possible en backend et que nous souhaitons ajouter cette création sur le front end.

cedfre commented 3 years ago

@benel @Hypertopic/competences-eut

Bonjour,

@theobour et moi passons sur cette page afin de répondre à vos interrogations et proposer une nouvelle versions de la maquette.

Nous sommes sur la page d’accueil et avons l'action "S'inscrire" sur le banque de navigation.

En cliquant sur ce lien l'utilisateur est redirigé vers le formulaire d'inscription. Le mot de passe est caché par défaut mais l’icône d’œil cliquable permet de le rendre visible lors de la saisie. Une fois ces champs remplis, l'utilisateur clique sur "Inscription".

Après l'inscription il est connecté et redirigé vers la page principale :

Pour les petits écran, notre bandeau s'adapte comme ceci :

Pour reprendre vos points :

Le bleu du bouton ne fait pas partie de la palette actuelle de Porphyry. L'ajout de la fonctionnalité nécessite-t-il la modification de la palette ?

Effectivement, dans la maquette ci-dessous nous avons modifié la couleur du bouton en prenant le code couleur des boutons de validation (#abd14b) de la palette.

Une convention en informatique consiste à ajouter des points de suspension à la suite du titre d'une action quand celle-ci nécessite plus qu'un simple clic pour être effectuée. On la voit dans "Se connecter..." mais pas dans "S'inscrire".

Tout à fait, nous avons modifier cela dans la nouvelle version de la maquette.

L'affichage des éléments du bandeau dans lequel vous avez placé "S'inscrire" diffère sur les terminaux de petite taille. Comment doit se comporter votre lien dans ce cas là ?

Sur les terminaux de petite taille nous avons réalisé une maquette pour visualiser l’affichage des éléments du bandeau. Nous nous adaptons au bandeau mobile existant en ajoutant l’élément “S’inscrire”.

Vous ajoutez de nombreux intitulés (j'en ai compté 9, peut-être plus si vous avez des "placeholders"). L'interface existant en deux langues, il faudrait aussi prévoir leur traduction en anglais.

Nous prendrons bien en compte l’interface en deux langues.

Je ne suis pas un expert en "expérience utilisateur", mais j'ai compris que l'effet bénéfique de la confirmation de mot de passe est loin d'être évident.

Dans la nouvelle maquette nous avons décidé de supprimer la confirmation de mot de passe et d’ajouter une icône d'œil pour visualiser le mot de passe lors de la saisie.

Le logiciel Porphyry est générique : votre formulaire ne sera pas utilisé que par des étudiants de l'Eut+ (il suffit de regarder les autres groupes d'IF05 pour voir la diversité des usages). Êtes-vous certains que les champs choisis seront adaptés aux autres domaines d'application ?
L'un des principes du RGPD est que les données personnelles collectées doivent être limitées à ce qui est nécessaire au regard des finalités poursuivies. Est-ce le cas de chacun de ces champs ? Autrement dit pouvez-vous expliciter à quoi servira chacun de ces champs et convaincre les usagers qu'on ne peut pas faire sans ?

Pour rendre notre formulaire d’inscription générique et conforme RGPD nous allons uniquement garder les champs suivants : pseudonyme, email, password.

Dans le bandeau du haut, en passant d'une action à deux (en plus de la place occupée par le logo et le titre), ça commence à être un peu chargé... Avez-vous envisagé des moyens de réduire la place utilisée par ces deux actions quand on n'est pas en train de s'en servir ?

Nous trouvons que si nous gardons uniquement ces deux actions, cela ne charge pas trop l’écran. Par ailleurs, une fois connecté, le bandeau affiche toujours uniquement deux éléments : le pseudonyme ainsi que “Se déconnecter”.

Vous avez fait le choix de mettre le formulaire en quasi-pleine page. Pourquoi pas... Aviez-vous envisagé d'autres solutions et comparé le pour et le contre ?

Pour une meilleure visibilité et afin que l’utilisateur puisse rapidement s’inscrire, nous avons décidé d’aller à l’essentiel en centrant le formulaire sur la page.

Tel que le formulaire est maquetté (si c'est bien le choix que vous choisissez de défendre) : il y a une petite ambiguïté pour l'implémenter : s'agit-il d'une nouvelle page (avec sa propre URI) ou par exemple d'une fenêtre modale qui apparaît au dessus de la fenêtre existante ?

Pour lever cette ambiguïté nous avons ajouté une barre d’URL en haut de la maquette afin de bien faire la distinction : il s’agit bien d’une nouvelle page.

Que se passe-t-il une fois que l'on a validé l'inscription ? Voit-on la page de laquelle on est parti ? Est-on connecté ? Que se passe-t-il si on annule ? Y a-t-il des cas dans lesquels la validation est impossible ?

Une fois l’inscription validée l’utilisateur est redirigé vers la page principale et il est directement connecté, c’est pour cela que son pseudonyme s’affiche désormais sur le bandeau. La validation par l’utilisateur est impossible si le pseudonyme est déjà utilisé par un autre utilisateur ou si l’email n’est pas de forme correct.

benel commented 3 years ago

@cedfre @theobour

Merci pour cette nouvelle version.

nous avons modifié la couleur du bouton en prenant le code couleur des boutons de validation (#abd14b) de la palette.

OK. Spontanément, j'aurais été plus sobre en adoptant le même gris que l'ajout de point de vue. Mais ça se tient.

Sur les terminaux de petite taille nous avons réalisé une maquette pour visualiser l’affichage des éléments du bandeau. Nous nous adaptons au bandeau mobile existant en ajoutant l’élément “S’inscrire”.

Du coup, en mobilité, on pourra s'inscrire mais pas se connecter... Et s'inscrire pour faire quoi ? Toutes les autres actions nécessitant une inscription ne sont-elles pas cachées ? Le design rationale derrière est qu'il est très peu probable de faire des éditions (et de toute manière ce serait beaucoup trop difficile et périlleux).

Dans la nouvelle maquette nous avons décidé de supprimer la confirmation de mot de passe et d’ajouter une icône d'œil pour visualiser le mot de passe lors de la saisie.

Entendu... Il faudra voir si ça peut être fait sans "surcoût" (sinon il faudra le garder pour une future amélioration).

Nous trouvons que si nous gardons uniquement ces deux actions, cela ne charge pas trop l’écran.

Vous vous en doutez une autre option aurait pu être de mettre un menu (d'ailleurs bootstrap sait passer d'un menu horizontal fixe à un menu vertical escamotable en fonction de la taille disponible). Mais j'entends votre argument.

Par ailleurs, une fois connecté, le bandeau affiche toujours uniquement deux éléments : le pseudonyme ainsi que “Se déconnecter”

Effectivement il faudra penser à cacher l'inscription une fois connecté.

Pour une meilleure visibilité et afin que l’utilisateur puisse rapidement s’inscrire, nous avons décidé d’aller à l’essentiel en centrant le formulaire sur la page.

Ce ne sont pas vraiment d'autres options. Mais bon, je vais arrêter de vous torturer ;)

Pour rendre notre formulaire d’inscription générique et conforme RGPD nous allons uniquement garder les champs suivants : pseudonyme, email, password.

OK. Pour le pseudonyme et le mot de passe, je m'imagine l'usage sans trop de difficultés... Quel sera (ou quels seront) le•s traitement•s lié•s à l'adresse électronique ?

Pour lever cette ambiguïté nous avons ajouté une barre d’URL en haut de la maquette afin de bien faire la distinction : il s’agit bien d’une nouvelle page.

OK... On pourra donc par exemple la partager ?

Pour lever cette ambiguïté nous avons ajouté une barre d’URL

C'est une bonne habitude quand on maquette une interface Web.

Une fois l’inscription validée l’utilisateur est redirigé vers la page principale et il est directement connecté, c’est pour cela que son pseudonyme s’affiche désormais sur le bandeau.

Vers la page principale ? Donc si l'usager avait déjà fait une sélection, par exemple, ou si elle était sur un item précis qu'elle voulait éditer, elle va devoir le chercher à nouveau ?

La validation par l’utilisateur est impossible si le pseudonyme est déjà utilisé par un autre utilisateur ou si l’email n’est pas de forme correct.

OK. Et si l'adresse électronique est déjà utilisée, on accepte ou on refuse ?

Plaisanterie mise à part, ne voyez aucun sadisme dans mes questions. Mon unique but est de vous aider, par mes questions, à vous poser toutes les questions de conception, le plus tôt possible dans le process.

theobour commented 3 years ago

Je réponds à vos dernières interrogations présentent dans votre précédent post.

Du coup, en mobilité, on pourra s'inscrire mais pas se connecter... Et s'inscrire pour faire quoi ? Toutes les autres actions nécessitant une inscription ne sont-elles pas cachées ? Le design rationale derrière est qu'il est très peu probable de faire des éditions (et de toute manière ce serait beaucoup trop difficile et périlleux).

En mobilité, c'est à dire sur un téléphone l'utilisateur pourra encore se connecter et s'inscrire. La dernière maquette qu'a posté @cedfre est une maquette téléphone. Elle montre bien que l'on souhaite rajouter "s'inscrire..." en dessous de "se connecter..." sans cacher l'un ou l'autre.

Vous vous en doutez une autre option aurait pu être de mettre un menu (d'ailleurs bootstrap sait passer d'un menu horizontal fixe à un menu vertical escamotable en fonction de la taille disponible).

Effectivement, cette solution est aussi envisageable.

OK. Pour le pseudonyme et le mot de passe, je m'imagine l'usage sans trop de difficultés... Quel sera (ou quels seront) le•s traitement•s lié•s à l'adresse électronique ?

Pour envoyer des mails à l'ensemble des utilisateurs par exemple ? Sinon nous pouvons retirer l'email et n'avoir que le pseudo et le mot de passe.

OK... On pourra donc par exemple la partager ? Par partage vous pensez à envoyer le lien direct de la page. Le cas échéant, comme l'inscription se fait sur une page à part entière alors oui ce sera possible.

Vers la page principale ? Donc si l'usager avait déjà fait une sélection, par exemple, ou si elle était sur un item précis qu'elle voulait éditer, elle va devoir le chercher à nouveau ?

Effectivement la sélection sera perdu. Par ailleurs, ce scénario d'usage permettant de sauvegarder la sélection durant l'inscription peut faire l'objet d'un nouveau ticket.

OK. Et si l'adresse électronique est déjà utilisée, on accepte ou on refuse ? Si l'adresse électronique est déjà utilisée alors l'inscription est refusée. Ce cas d'usage sera explicité dans le scénario.

benel commented 3 years ago

@theobour

En mobilité, c'est à dire sur un téléphone l'utilisateur pourra encore se connecter et s'inscrire. La dernière maquette qu'a posté @cedfre est une maquette téléphone. Elle montre bien que l'on souhaite rajouter "s'inscrire..." en dessous de "se connecter..." sans cacher l'un ou l'autre.

L'an dernier, le groupe qui a travaillé sur l'usage mobile de Porphyry a fait le choix judicieux de cacher tout ce qui permet de modifier les données (création d'item, de point de vue, modification d'attribut, de catégorie, édition de point de vue) afin de mieux utiliser la place disponible sur le terminal et par ailleurs d'éviter de corrompre les données suite à un clic malheureux.

Or "Se connecter" est nécessaire uniquement si on veut modifier les données (attributs, catégories, points de vue...). Si les étudiants de l'an dernier étaient allés jusqu'au bout de leur logique, ils auraient dû cacher également "Se connecter" dans l'interface mobile.

C'est pour cette raison que je souhaitais attirer votre attention sur le fait qu'il serait opportun de cacher "S'inscrire" sur les terminaux mobiles.

Pour vous ça ne change pas grand chose, mais c'est important pour ceux qui travaillent sur les usages mobiles de Porphyry (cette année : @Hypertopic/journees-du-patrimoine).

benel commented 3 years ago

@theobour @cedfre

OK. Pour le pseudonyme et le mot de passe, je m'imagine l'usage sans trop de difficultés... Quel sera (ou quels seront) le•s traitement•s lié•s à l'adresse électronique ?

Pour envoyer des mails à l'ensemble des utilisateurs par exemple ? Sinon nous pouvons retirer l'email et n'avoir que le pseudo et le mot de passe.

Je vois deux options possibles :

soit vous associez un traitement à l'adresse électronique (comme le fait de vérifier qu'il n'est pas déjà utilisé mais ce n'est pas forcément très facile à faire côté-backend),
soit, et c'est probablement plus sage, vous gardez l'ajout de l'adresse électronique pour la version améliorée (#361).

Vers la page principale ? Donc si l'usager avait déjà fait une sélection, par exemple, ou si elle était sur un item précis qu'elle voulait éditer, elle va devoir le chercher à nouveau ?

Effectivement la sélection sera perdu.

Si vous regardez sur la plupart des sites comment ça fonctionne, la page de création de compte possède en général un paramètre contenant l'URI de la page précédente : c'est justement pour reprendre où on en était (ce serait dommage par exemple sur un site de e-commerce de manquer une vente qui était en cours). Après vous pourriez aussi revenir par programme à la page précédente (en se servant de l'historique du navigateur), le problème c'est si on était sur un autre site...

cedfre commented 3 years ago

@benel @Hypertopic/competences-eut Voici notre travail avec @theobour pour nos scénarios

User Stories

En tant qu’utilisateur non enregistré, je peux m’inscrire. En tant qu'utilisateur enregistré, je peux me connecter. En tant qu’utilisateur authentifié, je peux me déconnecter.

Scénarios

Scénario: L’utilisateur n’est pas connecté

Soit l’utilisateur n’est pas connecté
Et ne possède pas de compte
Alors “S’inscrire…” est présent dans la barre de navigation

Scénario: L’utilisateur souhaite se rendre sur la page d’inscription

Soit l’utilisateur n’est pas connecté
Et ne possède pas de compte
Quand il clique sur “S’inscrire…” dans la barre de navigation
Alors il est redirigé vers la page d’inscription sur un autre URL

Scénario: L’utilisateur souhaite s’inscrire avec un e-mail au format non valide

Soit l’utilisateur est présent sur la page d’inscription
Étant donné qu’il a rempli le champ “E-mail” avec un e-mail au format non valide. Exemple “balabf” 
Quand il clique sur le bouton de validation “Inscription”
Alors un message d’erreur “E-mail invalide” s’affiche.

Scénario: L’utilisateur souhaite s’inscrire avec un e-mail déjà utilisé

Soit l’utilisateur est présent sur la page d’inscription
Étant donné qu’il a rempli le champ “E-mail” avec un e-mail déjà utilisé. 
Quand il clique sur le bouton de validation “Inscription”
Alors un message d’erreur “E-mail déjà utilisé” s’affiche

Scénario: L’utilisateur souhaite s’inscrire avec un pseudonyme déjà utilisé

Soit l’utilisateur est présent sur la page d’inscription
Étant donné qu’il a rempli le champ “Pseudonyme” avec un pseudonyme déjà utilisé.
Quand il clique sur le bouton de validation “Inscription”
Alors un message d’erreur “Pseudonyme déjà utilisé” s’affiche

Scénario: L’utilisateur souhaite finaliser son inscription

Soit l’utilisateur est présent sur la page d’inscription
Étant donné qu’il a rempli le champ “E-mail” avec un e-mail valide.
Étant donné qu’il a rempli le champ “Pseudonyme” avec un pseudonyme non utilisé.
Étant donné qu’il a rempli le champ “Mot de passe”.
Quand il clique sur le bouton de validation “Inscription”
Alors l’utilisateur est redirigé vers la page d’accueil en étant connecté à son compte nouvellement créé.

benel commented 3 years ago

@cedfre @theobour Merci pour cette première version de scénarios.

J'ai édité moi-même votre commentaire pour ajouter la coloration syntaxique : ça rend les choses quand même beaucoup plus lisibles. Si vous ne savez pas comment faire, vous pouvez regarder le source du commentaire en mode édition.

On va un peu reprendre à zéro (peut-être qu'ensuite vous pourrez réutiliser certaines de vos étapes) :

Pour le Quand, il faut reprendre le nom de la fonctionnalité ("S'enregistrer comme contributeur") et en faire une petite phrase en y ajoutant (entre guillemets) toutes les données dont on a besoin pour faire ça.
Ensuite vous devez vous interroger sur les différents cas induits par les données que vous avez choisi de passer en paramètre. Ce seront les différents Scénarios.
Enfin, demandez-vous comment on pourrait tester ce qui a changé entre "avant l'enregistrement" et "après".

Ne passez pas tout de suite à l'étape 3. Les deux premières sont déjà assez difficiles...

Samnoel95 commented 3 years ago

Avec @candalc nous avons réalisé la stratégie d'implémentation pour le ticket @benel , @Hypertopic/competences-eut

Voici notre travail :

Quelle partie du code sera impactée (classes, méthodes) ?

Plusieurs parties du code vont être impactées. Lors de l'inscription d'un utilisateur, on lui demande 3 paramètres : un login, un password et un email. Pour l'email, il va falloir se poser la question de la vérification de sa conformité. Cette fonctionnalité ne peut être implémentée que si le ticket #183 est passé en prod. La gestion de l'inscription semble se dérouler au niveau du composant Authenticated (components> Authenticated.jsx) de Porphyry.

render() {
   if (this.state.user) {
     return (
       <div className="Authenticated"> {this.state.user}
         <a href="#logout" onClick={this.handleLogout}><Trans>Se déconnecter</Trans></a>
       </div>
     );
   }
   if (this.state.ask) {
     return (
       <form className="Authenticated" onSubmit={this.handleLogin}>
         <input placeholder={i18n._(t`nom d'utilisateur`)} ref={(x) => this.login = x} />
         <input placeholder={i18n._(t`mot de passe`)} ref={(x) => this.password = x} type="password" />
         <input type="submit" value={i18n._(t`Se connecter`)} />
       </form>
     );
   }
   return (
     <div className="Authenticated">
       <a href="#login" onClick={this.handleAsk}><Trans>Se connecter...</Trans></a>
       // Rajouter le lien vers la page d'inscription, onClick redirige vers la page d'inscription
     </div>
   );
 }

Il faudrait alors rajouter un état “S’inscrire”, qui, au clic sur cet état, redirige vers une autre page où on récupère le login, l'email et le password de l’user au travers d'un formulaire. Le formulaire pourrait simplement être un nouveau composant React par exemple. Le code ci-dessous pourrait nous permettre de récupérer les informations liées à l'inscription de l'utilisateur, afin de lui créer son compte.

_fetchSession() {
   this.requestSession()
     .then(x => x.json())
     .then(x => this.setState({user: x.name || x.userCtx.name}))
     .catch(() => this.setState({user: ''}));
 }

 _openSession() {
   let user = this.login.value;
   this.requestSession({
     method: 'POST',
     headers: {
       'Content-Type': 'application/x-www-form-urlencoded',
     },
     body: `name=${user}&password=${this.password.value}`
   })
     .then(x => {
       if (!x.ok) throw new Error('Bad credentials!');
       this.setState({user});
     })
     .catch(() => this.setState({user: ''}));
 }

C'est à ce niveau-là qu'on peut valider ou non l'inscription : il faut penser à prendre en compte lors de l'implémentation les cas où l'inscription échoue. L’utilisateur est inscrit et est automatiquement connecté lors de son inscription si : l’input de login et celui du password ne sont pas vides, si le login n’est pas déjà utilisé et si l’adresse mail est de type email (ou définir une RegEx spécifique).

Il faut également penser au cas où l'utilisateur est déjà connecté : dans ces cas-là, comme pour la connexion, le bouton "S'inscrire" n'est pas visible. La gestion du style du bouton se fait dans le fichier App.css (src > styles > App.css).

Pour la redirection vers la page d'inscription, il existe plusieurs options. La première serait de modifier le composant dans le fichier index.js, en ajoutant un composant Register dans Authenticated.jsx, à importer dans l'index, pour définir le . Pour faire un path, la méthode semble être la suivante :

ReactDOM.render(
 <I18nProvider i18n={i18n} language="en" catalogs={catalogList}>
   <Router>
     <Switch>
       <Route path="/item/:corpus/:item" component={Item} />
       <Route path="/viewpoint/:id" component={Outliner} />
       <Route path="/" component={Portfolio} />
     </Switch>
   </Router>
 </I18nProvider>,
 document.getElementById('root')
);

// et dans le render de la méthode Authenticated mettre le lien vers “S’inscrire” de la même manière que ci-dessous

      // ...
       <div className="Status row h5">
         <Link to="/" className="badge badge-pill badge-light TopicTag">
           <span className="badge badge-pill badge-dark oi oi-chevron-left"> </span>
           <Trans>Retour à l'accueil</Trans>
         </Link>
       </div>
       <div className="container-fluid">

Si on n’applique pas la solution de la redirection vers une autre page (= URI différent), il est sinon possible de faire s'afficher un layer sur la page d'accueil au clic sur le bouton "S'inscrire", mais qui ne concorde pas avec les maquettes actuelles.

Y aura-t-il des difficultés d’un point de vue algorithmique ? Avez-vous des pistes pour les résoudre ?

Nous allons pouvoir utiliser des méthodes qui sont déjà globalement implémentées dans Porphyry (pas de back-end à faire normalement) pour implémenter la fonctionnalité. une partie importante va être de s'assurer de la gestion des erreurs lors de l'inscription : format des données correct, pas de doublons pour les logins, etc. Il faut aussi s’assurer de pouvoir récupérer l’ensemble des logins des utilisateurs de Porphyry déjà inscrits pour vérifier que le login d’inscription n’est pas déjà utilisé.

Les données dont vous avez besoin sont-elles déjà chargées par la page ? Si oui, quelle est la structure des données et comment allez-vous récupérer précisément celles qui vous intéressent ?

Non les données ne sont pas directement chargées dans page. Il faut récupérer la liste des utilisateurs déjà inscrits pour refuser une inscription si le pseudo est déjà utilisé, et il faut ensuite s'assurer de mettre les informations de l'user dans Argos. Les données relatives aux utilisateurs qui sont inscrits sur le site peuvent être récupérées depuis le proxy, mais on peut se contenter de ne récupérer que les logins des utilisateurs.

Existe-t-il des bibliothèques qui pourraient simplifier l’implémentation ? Doit-on intégrer des services extérieurs ?

Ne s’applique pas

Des étapes préalables de développement sont-elles envisageables pour diminuer la complexité de la livraison ?

Peu d'étapes de développement peuvent être fractionnables. On peut par contre envisager de développer dans un premier temps l'action de s'inscrire (affichage correct des composants, du formulaire et de la page d'inscription), puis dans un deuxième de s'assurer d'implémenter la gestion des erreurs lors de l'inscription (pas de doublons du login, la RegEx pour l'email, pas d'input vide).

benel commented 3 years ago

Merci @candalc et @Samnoel95 pour cette première version de la stratégie d'implémentation.

Globalement, c'est pas mal. C'est un très bon début. Mais il y a :

parfois quelques imprécisions de vocabulaire informatique,
des petits manques dans la recherche de références externes (API, standards ou bibliothèques),
un petit manque dans les tests du backend (avec REST Client).

vérification de sa conformité.

Quand on parle de "conformité" d'une adresse électronique, on pense plutôt à un problème de forme, de format. Le fait que l'utilisateur possède cette adresse, qu'il ait accès à la boîte correspondante est plus un problème de sécurité que de format.

La gestion de l'inscription semble se dérouler

Pour l'instant, elle ne se déroule pas puisqu'elle n'existe pas encore (par contre, on est d'accord que c'est une bonne idée de mettre cette future fonctionnalité là). Notez bien que l'on distingue en général l'inscription (register, sign up) de la connexion (authentication, log in).

Le code ci-dessous pourrait nous permettre de récupérer les informations liées à l'inscription de l'utilisateur, afin de lui créer son compte.

Là je n'ai pas trop compris... Le code que vous citez correspond à la création de la session. C'est différent de la création d'un utilisateur (toujours cette différence entre register et log in). Après, c'est vrai que c'est une requête vers le backend, de ce côté là ça se ressemble un peu... À ce propos, avez-vous vu quel est le nom de la méthode générique que l'on utilise pour faire les requêtes HTTP (et qui d'ailleurs est justement utilisée dans requestSession) ?

Pour la redirection vers la page d'inscription

"Vers" ou "depuis" ?

Nous allons pouvoir utiliser des méthodes qui sont déjà globalement implémentées dans Porphyry (pas de back-end à faire normalement)

S'il y a besoin, effectivement, je le ferai pour vous. Par contre, vous allez l'utiliser, du coup ce serait bien de le tester dès maintenant.

Avez-vous trouvé la documentation à propos de la création d'utilisateurs dans CouchDB ?
Avez-vous testé cette API (par exemple avec REST Client) sur votre CouchDB de test (port : 5984) ?
Avez-vous testé cette API à travers AAAforREST, votre reverse proxy local (port : 80) ? Est-ce que ça "passe" ou est-ce que je dois faire un petit développement pour vous ?

RegEx pour l'email, pas d'input vide

Avez-vous regardé si les versions récentes de HTML gèrent cela ?
À défaut, y aurait-il des bibliothèques qui permettent de gérer ça.

candalc commented 3 years ago

Là je n'ai pas trop compris... Le code que vous citez correspond à la création de la session.

C’est vrai qu’on a eu une confusion entre la création d’un compte (= l’inscription) et la création de la session..

Avez-vous trouvé la documentation à propos de la création d'utilisateurs dans CouchDB ? Avez-vous testé cette API sur votre CouchDB de test (port : 5984) ? Avez-vous testé cette API à travers AAAforREST, votre reverse proxy local (port : 80) ? Est-ce que ça "passe" ou est-ce que je dois faire un petit développement pour vous ?

Pour l’inscription, il faut faire une requête HTTP de type POST vers le back-end. On aurait aussi pu utiliser une requête PUT, mais une des principales différences est que POST n’est pas une méthode idempotente, et qu’avec une requête de type PUT, s’il existe déjà une ressource à une certaine URI, la requête modifie juste cette ressource. Pour CouchDB, d’après la documentation, la création d’utilisateur a l’air de se faire sur la table _users. Le format du json est le suivant :

{
  "_id": "org.couchdb.user:alice",
  "type": "user",
  "name": "alice",
  "password": "wonderland",
  "roles": []
}

On a pu tester l’API avec REST Client sur CouchDB en local, à la fois pour accéder à la table _users, mais aussi ajouter un utilisateur à cette table. Pour créer le compte de l’utilisateur, il faut penser, si l’on fait une requête POST, à mettre les headers correspondants (Content-type : application/json).

On a essayé de tester cette API à travers l’environnement de test de AAA, la requête semble passer également quand on fait un GET (Status Code : 200 OK) et un POST (Status Code : 201 Created).

Quand on parle de "conformité" d'une adresse électronique, on pense plutôt à un problème de forme, de format. Le fait que l'utilisateur possède cette adresse, qu'il ait accès à la boîte correspondante est plus un problème de sécurité que de format. Avez-vous regardé si les versions récentes de HTML gèrent cela ? À défaut, y aurait-il des bibliothèques qui permettent de gérer ça.

Effectivement, la vérification de l’adresse email doit se faire à la fois sur l’aspect conformité et sur l’aspect sécurité. On doit d’assurer que l’utilisateur saisi bien un email. Mais on doit aussi vérifier que l’email utilisé n’est pas déjà associé à un compte utilisateur. On peut d’ailleurs appliquer ces vérifications pour le login : limiter le login à des caractères alphabétiques et numériques (pour éviter les \ par exemple).

Pour gérer cette vérification, on peut le faire côté client avec HTML 5 avec la balise <input type=email>. Cependant, on peut, pour plus de sécurité, valider de la forme de l’email côté serveur. Plusieurs bibliothèques JS peuvent être utilisées pour les applications en React, comme Formik ou Validate.js. On peut aussi directement faire une fonction qui vérifie que l’email saisi dans le formulaire soit conforme à l’expression régulière.

benel commented 3 years ago

Merci @candalc (et votre binôme ?) pour cette nouvelle version de votre stratégie d'implémentation.

On avance, c'est bien !

Pour l’inscription, il faut faire une requête HTTP de type POST vers le back-end. On aurait aussi pu utiliser une requête PUT, mais une des principales différences est que POST n’est pas une méthode idempotente

C'est plutôt bien d'être idempotent... Mais pour être tout à fait exact, comme vous donnez l'identifiant dans le corps de la requête, votre POST devient également idempotent. Autrement dit, que vous le fassiez avec PUT ou POST, en envoyant plusieurs fois la même requête de création d'un utilisateur, il n'y a aucun risque d'en créer plusieurs.

On a pu tester l’API avec REST Client sur CouchDB en local, à la fois pour accéder à la table _users, mais aussi ajouter un utilisateur à cette table. Pour créer le compte de l’utilisateur, il faut penser, si l’on fait une requête POST, à mettre les headers correspondants (Content-type : application/json).

Super !

On a essayé de tester cette API à travers l’environnement de test de AAA, la requête semble passer également quand on fait un GET (Status Code : 200 OK) et un POST (Status Code : 201 Created).

Effectivement. Je vous l'avais demandé pour que vous soyez systématiques et parce que je n'en étais plus très sûr. Mais c'est géré depuis Juin dernier : https://github.com/Hypertopic/AAAforREST/commit/7ae1f27622e9004314c7100b2f47ca44f9200983

Mais on doit aussi vérifier que l’email utilisé n’est pas déjà associé à un compte utilisateur.

Vous voyez un cas dans lequel ce serait grave si ça l'était ?

Pour gérer cette vérification, on peut le faire côté client avec HTML 5 avec la balise . Cependant, on peut, pour plus de sécurité, valider de la forme de l’email côté serveur. Plusieurs bibliothèques JS peuvent être utilisées pour les applications en React, comme Formik ou Validate.js. On peut aussi directement faire une fonction qui vérifie que l’email saisi dans le formulaire soit conforme à l’expression régulière.

Le faire dans le frontend en React est effectivement une solution, cependant, comme vous l'indiquez HTML5 possède déjà un élément spécifique (qui permet précisément la validation par rapport à une expression régulière).

En conclusion, votre stratégie d'implémentation est très bien : il y a l'essentiel. Il manquerait peut-être juste un petit test du contrôle de la forme d'une addrese électronique avec les différentes options que vous indiquez (vous devriez trouver sur le net des pages d'exemple qui vous permettent de les tester).

Samnoel95 commented 3 years ago

"Mais on doit aussi vérifier que l’email utilisé n’est pas déjà associé à un compte utilisateur." Vous voyez un cas dans lequel ce serait grave si ça l'était ?

Ce ne serait pas forcément grave, mais souvent un utilisateur est associé à un unique compte (sauf dans le cadre de "comptes partagés", ce qui n'est pas le cas ici). Si on ne vérifie pas que l'email n'est pas déjà utilisé, on pourrait avoir des utilisateurs qui possèdent 2, 3, 4 comptes différents. Un étudiant et un enseignant n'auront normalement pas besoin d'avoir plusieurs comptes pour consulter ou modifier des ressources sur le site.

En conclusion, votre stratégie d'implémentation est très bien : il y a l'essentiel. Il manquerait peut-être juste un petit test du contrôle de la forme d'une addrese électronique avec les différentes options que vous indiquez (vous devriez trouver sur le net des pages d'exemple qui vous permettent de les tester).

On a pu tester via les exemples mis en ligne par les différentes bibliothèques. Les deux peuvent être installées facilement avec npm install. Pour Formik, ils proposent un exemple convaincant qui à l'air de bien prendre en compte tous les cas où l'email n'est pas valide. On peut également y rajouter le cas required pour que l'utilisateur ne laisse pas l'input email vide. Pour Validate.js, l'exemple en ligne est plus complet et traite l'ensemble du formulaire, dont des informations qui ne nous sont pas nécessaires. Les cas d'échec et de validation sont aussi assez exhaustifs.

Pour ces deux bibliothèques, on peut rajouter des cas d'utilisation custom, ou modifier la regex de validation de l'email si on en a besoin (autoriser uniquement les adresses mail des universités partenaires EUT+ par exemple ?). Pour Validate.js, ça se passe au niveau du PATTERN du fichier validate.js :

email: v.extend(function(value, options) {
    options = v.extend({}, this.options, options);
    var message = options.message || this.message || "is not a valid email";
    // Empty values are fine
    if (!v.isDefined(value)) {
         return; 
    } 
    if (!v.isString(value)) {
         return message; 
    }
    if (!this.PATTERN.exec(value)) {
         return message;
    }.  }, 
   { 
        PATTERN: /^(?:[a-z0-9!#$%&'*+/=?^_`{|}~-]+5[...] // On met la ou les regex qui nous intéressent
})

theobour commented 3 years ago

@cedfre @theobour Merci pour cette première version de scénarios.

J'ai édité moi-même votre commentaire pour ajouter la coloration syntaxique : ça rend les choses quand même beaucoup plus lisibles. Si vous ne savez pas comment faire, vous pouvez regarder le source du commentaire en mode édition.

On va un peu reprendre à zéro (peut-être qu'ensuite vous pourrez réutiliser certaines de vos étapes) :
1. Pour le `Quand`, il faut reprendre le nom de la fonctionnalité ("S'enregistrer comme contributeur") et en faire une petite phrase en y ajoutant (entre guillemets) toutes les données dont on a besoin pour faire ça.

2. Ensuite vous devez vous interroger sur les différents **cas** induits par les données que vous avez choisi de passer en paramètre. Ce seront les différents `Scénarios`.

3. Enfin, demandez-vous comment on pourrait tester ce qui a changé entre "avant l'enregistrement" et "après".
Ne passez pas tout de suite à l'étape 3. Les deux premières sont déjà assez difficiles...

N'étant pas sûr d'avoir bien compris, et souhaitant décoincer @cedfre sur l'écriture des scénarios, je fais un premier message pour vérifier ma compréhension.

J'ai réutilisé le dernier scénario en rédigeant mieux le "Quand". Est-ce mieux de cette façon ? Si oui, je le ferais ensuite pour l'ensemble des scénarios.
```
Scénario: L’utilisateur souhaite finaliser son inscription
```

Soit l’utilisateur est présent sur la page d’inscription Étant donné qu’il a rempli le champ “E-mail” avec un e-mail valide. Étant donné qu’il a rempli le champ “Pseudonyme” avec un pseudonyme non utilisé. Étant donné qu’il a rempli le champ “Mot de passe”. Quand l'utilisateur souhaite s'enregistrer en tant que contributeur Et l'utilisateur clique sur le bouton de validation “Inscription” Alors l’utilisateur est redirigé vers la page d’accueil en étant connecté à son compte nouvellement créé.



2. Nous avons en tout 3 données : email, pseudonyme et mot de passes. C'est pour cette raison que nous avons fait des scénarios si les données ne sont pas bonnes (mail utilisé, pseudonyme utilisé, email non valide...). Pour finir, les scénarios dans les précédents mails sont l'ensemble des cas induits par nos données et des actions utilisateurs possibles.

3. J'ai déjà une petite idée pour ce point. Pour tester le changement on pourra vérifier si un utilisateur a bien été crée dans la base de données répertoriant les utilisateurs et si la nouvelle entrée est en adéquation avec les données de l'utilisateur (pseudo et email)

benel commented 3 years ago

@cedfre @theobour

Bon, je vous fais la première étape :

Pour le Quand, il faut reprendre le nom de la fonctionnalité ("S'enregistrer comme contributeur") et en faire une petite phrase en y ajoutant (entre guillemets) toutes les données dont on a besoin pour faire ça.

Quand "bob@acme.org" s'enregistre comme contributeur en tant que "bob" avec le mot de passe "Ep0nge"

theobour commented 3 years ago

@benel

Est-ce plus juste désormais ? J'ai changé l'ensemble des "quand"

Scénario: L’utilisateur n’est pas connecté

Soit l’utilisateur n’est pas connecté
Et ne possède pas de compte
Quand l'utilisateur n'est pas connecté à un compte
Alors “S’inscrire…” est présent dans la barre de navigation

Scénario: L’utilisateur souhaite se rendre sur la page d’inscription

Soit l’utilisateur n’est pas connecté
Et ne possède pas de compte
Quand l'utilisateur souhaite s'enregistrer comme contributeur il clique sur “S’inscrire…” dans la barre de navigation
Alors il est redirigé vers la page d’inscription sur un autre URL

Scénario: L’utilisateur souhaite s’inscrire avec un e-mail au format non valide

Soit l’utilisateur est présent sur la page d’inscription
Étant donné qu’il a rempli le champ “E-mail” avec un e-mail au format non valide. Exemple : "bobaa.fr"
Quand "bobaa.fr" souhaite s'enregistre comme contributeur avec un format d'email non valide il clique sur le bouton de validation “Inscription”
Alors un message d’erreur “E-mail invalide” s’affiche.

Scénario: L’utilisateur souhaite s’inscrire avec un e-mail déjà utilisé

Soit l’utilisateur est présent sur la page d’inscription
Étant donné qu’il a rempli le champ “E-mail” avec un e-mail déjà utilisé. 
Quand "bob@utt.fr" souhaite s'enregistre comme contributeur avec un email déjà utilisé il clique sur le bouton de validation “Inscription”
Alors un message d’erreur “E-mail déjà utilisé” s’affiche

Scénario: L’utilisateur souhaite s’inscrire avec un pseudonyme déjà utilisé

Soit l’utilisateur est présent sur la page d’inscription
Étant donné qu’il a rempli le champ “Pseudonyme” avec un pseudonyme déjà utilisé.
Quand "bob@utt.fr" souhaite s'enregistre comme contributeur en tant que "bob" un pseudonyme déjà utilisé il clique sur le bouton de validation “Inscription”
Alors un message d’erreur “Pseudonyme déjà utilisé” s’affiche

Scénario: L’utilisateur souhaite finaliser son inscription

Soit l’utilisateur est présent sur la page d’inscription
Étant donné qu’il a rempli le champ “E-mail” avec un e-mail valide.
Étant donné qu’il a rempli le champ “Pseudonyme” avec un pseudonyme non utilisé.
Étant donné qu’il a rempli le champ “Mot de passe”.
Quand "bob@utt.fr" s'enregistre comme contributeur en tant que "bob" avec le mot de passe "Ep0nge"
Alors l’utilisateur est redirigé vers la page d’accueil en étant connecté à son compte nouvellement créé.

benel commented 3 years ago

@theobour Il y a des bonnes choses mais mélangées avec des choses inutiles... À mon avis vous avez trois fois trop de cas...

Plutôt que d'essayer de passer directement à une version finale, merci de suivre scrupuleusement les étapes que je vous doneées :

2. Ensuite vous devez vous interroger sur les différents **cas** induits par les données que vous avez choisi de passer en paramètre. Ce seront les différents `Scénarios`.

Quels sont les différents cas relatifs au courriel ? (consultez ce qui a été dit dans la discussion sur le fait que ce n'était pas forcément grave pour l'instant d'avoir plusieurs comptes avec le même courriel)
Quels sont les différents cas relatifs au mot de passe ?
Quels sont les différents cas relatifs au login ?

Notez qu'il n'est pas rare d'avoir un seul cas (!). Et même si vous choisissez d'en avoir deux ou trois, terminez d'abord le cas principal (validez le avec moi) avant de passer aux autres cas.

Hypertopic / Porphyry