Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Definition des cas d'usage #9

Open
psouquet opened this issue Jan 8, 2019 · 5 comments
Open

Definition des cas d'usage #9

psouquet opened this issue Jan 8, 2019 · 5 comments

Comments

@psouquet
Copy link
Member

psouquet commented Jan 8, 2019

Les cas d'usage sont visibles sur le gitbook. Merci de les relire et donner vos retours.

J'ai fait une premiere passe, il y a des points que je comprends pas (ce que j'ai barré ou où j'ai ajouté un point d'interrogation).
Si Vincent ou Christophe peuvent éclaire ces points (je pense qu'il y a une bonne partie d'erreur de copié collé) avant que je les supprimes bêtement :)

Aussi, vous pouvez proposer ici les cas d'usage à ajouter ou modifier, en fonction on pourra créer des issues pour en parler au besoin.

@cdeneux
Copy link
Member

cdeneux commented Jan 18, 2019

Je pense qu'il manque les cas d'usage suivants:

  • Sécuriser un espace de travail: on doit pouvoir préciser quel utilisateur à accès à tel espace de travail. Le rôle de l'utilisateur est aussi à préciser par espace de travail. La seule mention de cette sécurisation apparait dans le use-case Créer un nouvel espace de travail.

Remarques sur cas d'usage:

  • Quitter un espace de travail: je ne comprends à quoi il sert. Ca veut dire quoi "Quitter un espace de travail" ?
  • Supprimer un espace de travail: je pense que si un utilisateur est en train d'utiliser un espace qui est supprimé concuremment, un message d'information doit s'afficher pour lui dire que l'espace vient d'être supprimer. Ca ne me semble pas une bonne idée et ca ne me semble pas trop avoir de sens qu'il puisse continuer à voir des infos. Après le message d'information de la suppression, l'utilsateur devrait être redirigé sur les cas d'usage Charger un espace de travail ou Créer un nouvel espace de travail.
  • Sélectionner une topologie: je ne comprends pas ce cas d'usage. Que veut dire selectionner une topologie ?
  • Visualiser une topologie: Quid des noeuds de registry ?
  • Supprimer une topologie: même remarque que pour Supprimer un espace de travail.

@christophechevalier
Copy link
Member

Sécuriser un espace de travail est à définir oui c'est pour cela que je n'ai rien écris dessus pour le moment.

Quitter un espace de travail revient à dire "Je ne veux plus être membre de cet espace".

Supprimer un espace de travail est un cas particulier. Mais si jamais un autre utilisateur consulte l'espace au même moment, c'est aussi bien qu'il est le temps s'apercevoir que l'espace n'existe plus.
Oui, après le message d'information de la suppression, l'utilsateur est redirigé sur les cas d'usage Ouvrir un espace de travail ou Créer un espace de travail.

Sélectionner une topologie revient à dire Sélectionner un bus. Si l'utilisateur se trouve sur la vue de son espace de travail, alors aucunne topologie n'est sélectionnée. L'utilisateur aura le choix entre sélectionner son bus dans la liste depuis l'espace ou dans la vue de l'arbre (onglet topologie actif).

Concernant Visualiser une topologie et ta remarque sur les noeuds de registry, actuellement, cockpit de le gère pas. Je pense que nous aborderons le sujet activement peu de temps avant le refactor de la vue topologie ... mais rien nous empêche dans discuter ici. @vincent-zurczak @psouquet @cdeneux

Pour ma part, je souhaiterais soulever un point concernant les noms identiques des espaces de travail.
Actuellement, on peut avoir 2 même noms et description. Seul l'ID est unique.
Est ce pas un problème si un utilisateur à la possibilitée de créer plusieurs fois un espace de travail avec le même nom en sachant qu'à terme, la liste affichera tous les espaces de travail même ceux auquel l'utilisateur connecté n'a pas accès ?
Exemple :

  • CD35
  • CD35
  • CD35
  • Démo linagora
  • Démo linagora
  • ...
    On peut vite s'y perdre non ?

@psouquet
Copy link
Member Author

La discussion sur les rôles et permissions couvre le besoin de sécuriser un espace je pense. On peut l'ajouter aux besoins.

Pour ce qui est des noms des workspaces, je pense qu'ils devraient être unique.

@christophechevalier
Copy link
Member

@cdeneux @vincent-zurczak Nous avons besoin d'une réponse de votre part sur l'unicité d'un nom de workspace. Merci.

@cdeneux
Copy link
Member

cdeneux commented Apr 11, 2019

Oui, les noms de workspaces doivent être uniques sinon c'est confusion assurée

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants