Question : logique pour modification du numéro de la place

[vwilliam]

Lors de la modification du numéro de la place, quelle logique faut-il choisir si l'utilisateur a déjà libéré sa place ? Que faire dans la cas où cette place a déjà réservée ?

Quelle règle lors de la modification d'un numéro de place appliquer?
Voir le cas de la suppression , ou attribution d'une place par l'administrateur. (Supprimer cette fonctionnalité à l'utilisateur ?)

[lefevre00]

Apparemment da15e9a fixe la question ?

[atamd]

Ce qui a été fait concerne l'interdiction à un user de modifier le n° de sa place.
La question qui se pose :

Si l'admin modifie un n° de place et que cette dernière a été libérée pour une date à venir (place peut être inoccupée ou réservée par un autre utilisateur) . Que doit-on faire dans ce cas :

• mettre à jour les dates à venir avec le nouveau n° place et avertir l'occupant
• annuler les partages et réservations et avertir les éventuels occupants
• ne rien faire et laisser l'admin gérér à la mano.

Si place est réattribuée à une autre personne, il faut dans ce cas:

• annuler les partages et réservations et avertir les éventuels occupants

Je ne sais pas si j'a zappé d'autres cas !

[lefevre00]

Cette discussion m'amène à l'idée suivante :
Un utilisateur partage sa place, quelqu'en soit le numéro

L'impacte est de stocker qui partage une place plutôt que quelle place est partagée.
Du coup, on renommerait la table Place en Partage, avec dans partage la référence de l'utilisateur qui partage, plutot que le numéro de la place.

Ainsi, tout changement d'affectation de place n'aurait pas d'incidence... sauf lors de la migration, mais c'est un script qui le ferait.

[atamd]

Je pense qu'une réflexion plus approfondie pour améliorer l'outil au niveau de la BD et même du code source doit se faire.
Michael, ce que tu as dit est une autre façon d faire mais une intervention de mise à jour avec envoi de mail se fera quand même avec ta proposition (pas dans tous les cas de figures).
Pour le moment, pour moi, on doit avoir un outil fonctionnel sans bug.
J'ai peur que l'impact de ce changement soit lourd !
Une fois la version fonctionnelle figée. On continuera nous de notre côté à améliorer notre code pour avoir un outil robuste et PARFAIT ;-)

[lefevre00]

Absolument d'accord avec la nécessité de stabiliser.

Dans ce sens, il est impératif de gérer les ano-evolutions et de les flagger comme telles via "label".
Ensuite, définir ce qui sera dans la prochaine version stable.
Pour cela github propose les milestone (les voir comme des sprints selon moi).
Dites-moi si vous arriver a gérer milestone et issue ou si cela dépend du propriétaire du projet.