Priorité
Conception du modèle PriorityItem
Une priorité :
- Est le modèle central du module
- Matérialise physiquement (en BDD) la priorité de vente d'un contact donné.
- Vise une liste d'un ou plusieurs
ModeleArticle(Portée) à travers saPriorityetPriorityRange - Est toujours lié à un contact
- Peut être lié à une
PlaceLogique - Verrouille les
ArticlePlaceMatchen conséquence - Peut avoir un
Articled'origine (si généré via un achat) - Peut être lié à un
Articlerésultat (si utilisé)
classDiagram
class PriorityItem {
+bigint id
+bigint article_id
+bigint priority_id
+bigint contact_id
+bigint place_logique_id
+datetime date_debut
+datetime date_fin
}
PriorityItem "1" <--> "0..n" Priority
PriorityItem "0..1" <--> "0..n" PlaceLogique
PriorityItem "0..n" <--> "0..n" ArticlePlaceMatch : computed
Dates
Dates pendant lesquelles la priorité est fonctionnelle.
Articles
L'article est celui qui a généré la priorité de vente.
Les articles sont ceux ayant été achetés avec la priorité.
Place logique
La place logique (optionnelle) verrouillée par la priorité de vente.
Les ArticlePlaceMatch
Relation (ou vue) servant à verrouiller réellement les places.
Si une priorité de vente (PriorityItem) doit être générée sur des ArticlePlaceMatch déjà en lien avec une autre priorité, il y a alors conflit.
Quand on détecte un conflit, la nouvelle priorité est généré en état de conflit, avec lien vers la ou les sources de conflit, afin de permettre au gestionnaire de régler le souci si besoin.
Fonctions
Accès aux ModeleArticle
Selon la configuration de la Priority,
le Contact peut avoir accès à des ModeleArticle en ignorant d'autres règles de disponibilité.
Verrouillage des places
Tant qu'un PriorityItem valide verrouille des ArticlePlaceMatch,
ces derniers ne sont disponibles QUE pour le Contact de cette dernière.
Pour la récupération des ArticlePlaceMatch :
On stocke ces derniers en BDD.
Problème : si évolution des Event concernés, il faut recalculer la relation (cf modification des articles en cas de mise à jour des formules).