Views
PurchaseItemList = TypeAdapter(list[PurchaseItemSchema])
module-attribute
¶
BillingInfoForm
¶
Bases: ModelForm
Counter
¶
Bases: Model
gen_token()
¶
barmen_list()
¶
get_random_barman()
¶
update_activity()
¶
can_refill()
¶
Show if the counter authorize the refilling with physic money.
Source code in counter/models.py
get_top_barmen()
¶
Return a QuerySet querying the office hours stats of all the barmen of all time of this counter, ordered by descending number of hours.
Source code in counter/models.py
get_top_customers(since=None)
¶
Return a QuerySet querying the money spent by customers of this counter since the specified date, ordered by descending amount of money spent.
Each element of the QuerySet corresponds to a customer and has the following data :
- the full name (first name + last name) of the customer
- the nickname of the customer
- the amount of money spent by the customer
Parameters:
Name | Type | Description | Default |
---|---|---|---|
since
|
datetime | date | None
|
timestamp from which to perform the calculation |
None
|
Source code in counter/models.py
get_total_sales(since=None)
¶
Compute and return the total turnover of this counter since the given date.
By default, the date is the start of the current semester.
Parameters:
Name | Type | Description | Default |
---|---|---|---|
since
|
datetime | date | None
|
timestamp from which to perform the calculation |
None
|
Returns:
Type | Description |
---|---|
CurrencyField
|
Total revenue earned at this counter. |
Source code in counter/models.py
Customer
¶
Bases: Model
Customer data of a User.
It adds some basic customers' information, such as the account ID, and is used by other accounting classes as reference to the customer, rather than using User.
can_buy: bool
property
¶
Check if whether this customer has the right to purchase any item.
This must be not confused with the Product.can_be_sold_to(user) method as the present method returns an information about a customer whereas the other tells something about the relation between a User (not a Customer, don't mix them) and a Product.
save(*args, allow_negative=False, is_selling=False, **kwargs)
¶
is_selling : tell if the current action is a selling allow_negative : ignored if not a selling. Allow a selling to put the account in negative Those two parameters avoid blocking the save method of a customer if his account is negative.
Source code in counter/models.py
get_or_create(user)
classmethod
¶
Work in pretty much the same way as the usual get_or_create method, but with the default field replaced by some under the hood.
If the user has an account, return it as is. Else create a new account with no money on it and a new unique account id
Example : ::
user = User.objects.get(pk=1)
account, created = Customer.get_or_create(user)
if created:
print(f"created a new account with id {account.id}")
else:
print(f"user has already an account, with {account.id} € on it"
Source code in counter/models.py
Product
¶
Bases: Model
A product, with all its related information.
is_owned_by(user)
¶
Method to see if that object can be edited by the given user.
Source code in counter/models.py
can_be_sold_to(user)
¶
Check if whether the user given in parameter has the right to buy this product or not.
This must be not confused with the Customer.can_buy() method as the present method returns an information about the relation between a User and a Product, whereas the other tells something about a Customer (and not a user, they are not the same model).
Returns:
Type | Description |
---|---|
bool
|
True if the user can buy this product else False |
Warning
This performs a db query, thus you can quickly have a N+1 queries problem if you call it in a loop. Hopefully, you can avoid that if you prefetch the buying_groups :
Source code in counter/models.py
BasketForm(request)
¶
Class intended to perform checks on the request sended to the server when the user submits his basket from /eboutic/.
Because it must check an unknown number of fields, coming from a cookie and needing some databases checks to be performed, inheriting from forms.Form or using formset would have been likely to end in a big ball of wibbly-wobbly hacky stuff. Thus this class is a pure standalone and performs its operations by its own means. However, it still tries to share some similarities with a standard django Form.
Examples:
::
def my_view(request):
form = BasketForm(request)
form.clean()
if form.is_valid():
# perform operations
else:
errors = form.get_error_messages()
# return the cookie that was in the request, but with all
# incorrects elements removed
cookie = form.get_cleaned_cookie()
You can also use a little shortcut by directly calling form.is_valid()
without calling form.clean()
. In this case, the latter method shall be
implicitly called.
Source code in eboutic/forms.py
clean()
¶
Perform all the checks, but return nothing.
To know if the form is valid, the is_valid()
method must be used.
The form shall be considered as valid if it meets all the following conditions
- it contains a "basket_items" key in the cookies of the request given in the constructor
- this cookie is a list of objects formatted this way :
[{'id': <int>, 'quantity': <int>, 'name': <str>, 'unit_price': <float>}, ...]
. The order of the fields in each object does not matter - all the ids are positive integers
- all the ids refer to products available in the EBOUTIC
- all the ids refer to products the user is allowed to buy
- all the quantities are positive integers
Source code in eboutic/forms.py
is_valid()
¶
Return True if the form is correct else False.
If the clean()
method has not been called beforehand, call it.
Source code in eboutic/forms.py
Basket
¶
Bases: Model
Basket is built when the user connects to an eboutic page.
from_session(session)
classmethod
¶
The basket stored in the session object, if it exists.
generate_sales(counter, seller, payment_method)
¶
Generate a list of sold items corresponding to the items of this basket WITHOUT saving them NOR deleting the basket.
Example
counter = Counter.objects.get(name="Eboutic")
sales = basket.generate_sales(counter, "SITH_ACCOUNT")
# here the basket is in the same state as before the method call
with transaction.atomic():
for sale in sales:
sale.save()
basket.delete()
# all the basket items are deleted by the on_delete=CASCADE relation
# thus only the sales remain
Source code in eboutic/models.py
BasketItem
¶
Bases: AbstractBaseItem
from_product(product, quantity, basket)
classmethod
¶
Create a BasketItem with the same characteristics as the product passed in parameters, with the specified quantity.
Warning
the basket field is not filled, so you must set it yourself before saving the model.
Source code in eboutic/models.py
Invoice
¶
Bases: Model
Invoices are generated once the payment has been validated.
InvoiceItem
¶
Bases: AbstractBaseItem
PurchaseItemSchema
¶
Bases: Schema
BillingInfoState
¶
Bases: Enum
EbouticCommand
¶
Bases: LoginRequiredMixin
, TemplateView
EtransactionAutoAnswer
¶
Bases: View
get_eboutic_products(user)
¶
Source code in eboutic/models.py
eboutic_main(request)
¶
Main view of the eboutic application.
Return an Http response whose content is of type text/html. The latter represents the page from which a user can see the catalogue of products that he can buy and fill his shopping cart.
The purchasable products are those of the eboutic which belong to a category of products of a product category (orphan products are inaccessible).
If the session contains a key-value pair that associates "errors" with a list of strings, this pair is removed from the session and its value displayed to the user when the page is rendered.