Les modèles du BdA sont mal foutus #229
Labels
No labels
devtype -- backend
devtype -- docs
devtype -- frontend
devtype -- user interface
difficulty -- easy
difficulty -- hard
difficulty -- normal
Doing
domain -- bda
domain -- bds
domain -- cof
domain -- core
domain -- kfet
Good first issue
priority -- high
priority -- low
priority -- medium
priority -- staff-wanted
status -- development
status -- discussion
status -- need review
status -- production
status -- ready to merge
status -- todo
To Do
type -- bug
type -- hygiene
type -- improvement
type -- new feature
bug
duplicate
enhancement
help wanted
invalid
question
wontfix
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference: DGNum/gestioCOF#229
Loading…
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Chaque
User
peut avoir plusieursParticipant
s, un par tirage… C'est pas pratique. Ma proposition :Participant
devrait s'appelerBDAProfile
et avoir un champ many-to-manysubscriptions
vers les tirages auquels la personne est inscriteDans la table
through
entreBDAProfile
etTirage
on devrait stocker la liste des vœux et des attributions (enfin ces deux tables devraient avoir une foreign-key vers le trough plus exactement)Les reventes seront grandement simplifiées avec un
Participant
unique par personneUn avis là dessus ? Ce plan d'attaque ↑ mérite une review avant que je m'y attaque
Du coup, tu mettrais quels champs dans
BdAProfile
?Parmi les champs actuels de
Participant
, je ne garderais queaccepte_charte
J'ajouterais
subscriptions
(outirages
si le nom convient mieux)J'ajouterais
mailing_bda
etmailing_bda_revente
qui sont actuellement dansCOFProfile
Et à la réflexion je mettrais même
choices_revente
je pense.marked this issue as related to #276