Views
PurchaseItemList = TypeAdapter(list[PurchaseItemSchema])
module-attribute
¶
BillingInfoForm
¶
Bases: ModelForm
Counter
¶
Bases: Model
gen_token()
¶
get_barmen_list()
¶
Returns the barman list as list of User.
Also handle the timeout of the barmen
Source code in counter/models.py
get_random_barman()
¶
update_activity()
¶
is_inactive()
¶
Returns True if the counter self is inactive from SITH_COUNTER_MINUTE_INACTIVE's value minutes, else False.
Source code in counter/models.py
barman_list()
¶
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 |
Warns:
Type | Description |
---|---|
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.
Source code in eboutic/models.py
Invoice
¶
Bases: Model
Invoices are generated once the payment has been validated.
InvoiceItem
¶
Bases: AbstractBaseItem
PurchaseItemSchema
¶
Bases: Schema
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.