Definition des cas d'usage
psouquet opened this issue · comments
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.
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.
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 ?
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.
@cdeneux @vincent-zurczak Nous avons besoin d'une réponse de votre part sur l'unicité d'un nom de workspace. Merci.
Oui, les noms de workspaces doivent être uniques sinon c'est confusion assurée