d16a207a83
* ruff: apply rule F * ruff: apply rule E * ruff: apply rule SIM * ruff: apply rule TCH * ruff: apply rule ERA * ruff: apply rule PLW * ruff: apply rule FLY * ruff: apply rule PERF * ruff: apply rules FURB & RUF |
||
---|---|---|
.. | ||
migrations | ||
static/eboutic | ||
templates/eboutic | ||
tests | ||
__init__.py | ||
admin.py | ||
api.py | ||
converters.py | ||
forms.py | ||
models.py | ||
README.md | ||
schemas.py | ||
urls.py | ||
views.py |
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 :
eboutic_main
(GET) : 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. Si cette vue est appelée lors d'une redirection parce qu'une erreur est survenue au cours de la navigation sur la boutique, il est possible de donner les messages d'erreur à donner à l'utilisateur dans la session avec la clef"errors"
.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.EbouticCommand
(POST) : traite la soumission d'un panier par l'utilisateur. Lors de l'appel de cette vue, la requête doit contenir un cookie avec l'état du panier à valider. Ce panier doit strictement être de la forme :
[
{"id": <int>, "name": <str>, "quantity": <int>, "unit_price": <float>},
{"id": <int>, "name": <str>, "quantity": <int>, "unit_price": <float>},
<etc.>
]
Si le panier est mal formaté ou contient des valeurs invalides,
une redirection est faite vers eboutic_main
.
pay_with_sith
(POST) : paie le panier avec l'argent présent sur le compte AE. Redirige verspayment_result
.ETransactionAutoAnswer
(GET) : vue destinée à communiquer avec le service de paiement bancaire pour valider ou non le paiement de l'utilisateur.
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 vuepayment_result
.eboutic_makecommand.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 vueEbouticCommand
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 un cookie. Au moment de la validation du panier, ce cookie est envoyé au serveur pour vérifier que la commande est valide et payer.
Les modèles
Basket
: représente le panier d'un utilisateur. Un objetBasket
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é parBasketItem
etInvoiceItem
. Me demandez pas pourquoiproduct_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èleProduct
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.