Sith/eboutic/README.md

Eboutic
=======

# Aperçu général

L'application eboutic contient les vues, les templates et les modèles
nécessaires pour le fonctionnement de la boutique en ligne.
L'utilisateur peut acheter des produits en ligne et payer soit 
par carte bancaire soit avec l'argent qu'il possède sur son compte AE.

On effectue ici une séparation entre plusieurs types de produits : 
- les recharges de compte (``Refilling``) qui permettent de rajouter de 
l'argent sur le compte. Un panier contenant un élément de ce type ne pourra être
payé que par carte bancaire.
- Les cotisations (``Subscription``) qui permettent à un utilisateur de cotiser
à l'AE. Seul un utilisateur ayant déjà été cotisant pourra acheter ce produit.
Les primo-cotisants doivent s'adresser directement à un membre du bureau.
- Les produits normaux (badges, écussons, billets pour les soirées...)

Les utilisateurs cotisants ne peuvent pas voir les produits des non-cotisants
et vice-versa. Ce n'est pas la manière la plus satisfaisante de procéder, mais
c'est celle qui touchait le moins aux tables déjà en place.
Les produits avec une limite d'âge ne seront pas visibles par les utilisateurs ayant
un âge inférieur.

Le comportement de cette application dépend directement de celui des applications
``core`` et ``counter``. Les modèles de l'application ``Subscription`` sont
également utilisés. N'hésitez donc pas à vous pencher sur le fonctionnement des modules
susnommés afin de comprendre comment celui-ci marche.

# Les vues

Cette application contient les vues suivantes : 

- `EbouticMainView` (GET/POST) : la vue retournant la page principale de la boutique en ligne.
Cette vue effectue un filtrage des produits à montrer à l'utilisateur en
fonction de ce qu'il a le droit d'acheter.
Elle est en charge de récupérer le formulaire de création d'un panier et
redirige alors vers la vue de checkout.
- ``payment_result`` (GET) : retourne une page assez simple disant à l'utilisateur
si son paiement a échoué ou réussi. Cette vue est appelée par redirection
lorsque l'utilisateur paye son panier avec son argent du compte AE.
- ``EbouticCheckout`` (GET/POST) : Page récapitulant le contenu d'un panier.
Permet de sélectionner le moyen de paiement et de mettre à jour ses coordonnées
de paiement par carte bancaire.
- ``PayWithSith`` (POST) : paie le panier avec l'argent présent sur le compte
AE. Redirige vers `payment_result`.
- ``ETransactionAutoAnswer`` (GET) : vue destinée à communiquer avec le service 
de paiement bancaire pour valider ou non le paiement de l'utilisateur.
- ``BillingInfoFormFragment`` (GET/POST) : vue destinée à gérer les informations de paiement de l'utilisateur courant.

# Les templates

- ``eboutic_payment_result.jinja`` : très court template contenant juste
un message pour dire à l'utilisateur si son achat s'est bien déroulé.
Retourné par la vue ``payment_result``.
- ``eboutic_checkout.jinja`` : template contenant un résumé du panier et deux
boutons, un pour payer avec le site AE et l'autre pour payer par carte bancaire.
Retourné par la vue ``EbouticCheckout``
- ``eboutic_billing_info.jinja`` : formulaire de modification des coordonnées bancaires.
Elle permet également de mettre à jour ses coordonnées de paiement
- ``eboutic_main.jinja`` : le plus gros template de cette application. Contient
une interface pour que l'utilisateur puisse consulter les produits et remplir
son panier. Les opérations de remplissage du panier se font entièrement côté client.
À chaque clic pour ajouter ou retirer un élément du panier, le script JS
  (AlpineJS, plus précisément) édite en même temps le localStorage du navigateur. 
Cette vue fabrique dynamiquement un formulaire qui sera soumis au serveur.

# Les modèles

- ``Basket`` : représente le panier d'un utilisateur. Un objet ``Basket`` est créé
quand l'utilisateur soumet son panier et supprimé quand le paiement est validé.
Si le paiement n'est pas validé, le panier est conservé en base de données
afin d'avoir une trace si l'utilisateur a quand même été débité et qu'il n'a pas
reçu ses produits à cause d'une erreur de synchronisation.
- ``Invoice`` : Un peu comme un panier, mais pour quand une transaction
a été validée.
- ``AbstractBaseItem`` : modèle utilisé pour être hérité par ``BasketItem`` et ``InvoiceItem``.
Me demandez pas pourquoi ``product_id`` est un IntegerField plutôt qu'une clef étrangère,
moi aussi je trouve ça complètement con. 
Le prix unitaire est indiqué dans ce modèle même si ça fait une redondance avec le modèle
``Product`` afin de garder le prix que l'élément avait au moment de sa vente,
même si le prix du produit de base est modifié.
- ``BasketItem`` : représente un élément présent dans le panier de l'utilisateur.
- ``InvoiceItem`` : représente un élément vendu.