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…
Add table
Add a link
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
Userpeut avoir plusieursParticipants, un par tirage… C'est pas pratique. Ma proposition :Participantdevrait s'appelerBDAProfileet avoir un champ many-to-manysubscriptionsvers les tirages auquels la personne est inscriteDans la table
throughentreBDAProfileetTirageon 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
Participantunique 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_charteJ'ajouterais
subscriptions(outiragessi le nom convient mieux)J'ajouterais
mailing_bdaetmailing_bda_reventequi sont actuellement dansCOFProfileEt à la réflexion je mettrais même
choices_reventeje pense.marked this issue as related to #276