Views
EbouticBasketForm = forms.formset_factory(ProductForm, formset=BaseEbouticBasketForm, absolute_max=None, min_num=1)
module-attribute
¶
CanViewMixin
¶
Bases: GenericContentPermissionMixinBuilder
Ensure the user has permission to view this view's object.
Raises:
Type | Description |
---|---|
PermissionDenied
|
if the user cannot edit this view's object. |
IsSubscriberMixin
¶
Bases: AccessMixin
Check if the user is a subscriber.
Raises:
Type | Description |
---|---|
PermissionDenied
|
if the user isn't subscribed. |
FragmentMixin
¶
Bases: TemplateResponseMixin
, ContextMixin
Make a view buildable as a fragment that can be embedded in a template.
Most fragments are used in two different ways : - in the request/response cycle, like any regular view - in templates, where the rendering is done in another view
This mixin aims to simplify the initial fragment rendering. The rendered fragment will then be able to re-render itself through the request/response cycle if it uses HTMX.
Example
class MyFragment(FragmentMixin, FormView):
template_name = "app/fragment.jinja"
form_class = MyForm
success_url = reverse_lazy("foo:bar")
# in another view :
def some_view(request):
fragment = MyFragment.as_fragment()
return render(
request,
"app/template.jinja",
context={"fragment": fragment(request)
}
# in urls.py
urlpatterns = [
path("foo/view", some_view),
path("foo/fragment", MyFragment.as_view()),
]
reload_on_redirect = False
class-attribute
instance-attribute
¶
If True, this fragment will trigger a full page reload on redirect.
UseFragmentsMixin
¶
Bases: ContextMixin
Mark a view as using fragments.
This mixin is not mandatory
(you may as well render manually your fragments in the get_context_data
method).
However, the interface of this class bring some distinction
between fragments and other context data, which may
reduce boilerplate.
Example
class FooFragment(FragmentMixin, FormView): ...
class BarFragment(FragmentMixin, FormView): ...
class AdminFragment(FragmentMixin, FormView): ...
class MyView(UseFragmentsMixin, TemplateView)
template_name = "app/view.jinja"
fragments = {
"foo": FooFragment
"bar": BarFragment(template_name="some_template.jinja")
}
fragments_data = {
"foo": {"some": "data"} # this will be passed to the FooFragment renderer
}
def get_fragments(self):
res = super().get_fragments()
if self.request.user.is_superuser:
res["admin_fragment"] = AdminFragment
return res
get_fragment_data()
¶
get_fragment_context_data()
¶
Return the rendered fragments as context data.
Source code in core/views/mixins.py
BaseBasketForm
¶
Bases: BaseFormSet
BillingInfoForm
¶
Bases: ModelForm
ProductForm(customer, counter, allowed_products, *args, **kwargs)
¶
Bases: Form
Source code in counter/forms.py
BillingInfo
¶
Bases: Model
Represent the billing information of a user, which are required by the 3D-Secure v2 system used by the etransaction module.
to_3dsv2_xml()
¶
Convert the data from this model into a xml usable
by the online paying service of the Crédit Agricole bank.
see : https://www.ca-moncommerce.com/espace-client-mon-commerce/up2pay-e-transactions/ma-documentation/manuel-dintegration-focus-3ds-v2/principes-generaux/#integration-3dsv2-developpeur-webmaster
.
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
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, **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
update_returnable_balance()
¶
Update all returnable balances of this user to their real amount.
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
Selling
¶
Bases: Model
Handle the sellings.
save(*args, allow_negative=False, **kwargs)
¶
allow_negative : Allow this selling to use more money than available for this user.
Source code in counter/models.py
Basket
¶
Bases: Model
Basket is built when the user connects to an eboutic page.
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
BillingInfoState
¶
Bases: Enum
Invoice
¶
Bases: Model
Invoices are generated once the payment has been validated.
InvoiceItem
¶
Bases: AbstractBaseItem
BaseEbouticBasketForm
¶
Bases: BaseBasketForm
EbouticMainView
¶
Bases: LoginRequiredMixin
, FormView
Main view of the eboutic application.
The purchasable products are those of the eboutic which belong to a category of products of a product category (orphan products are inaccessible).
EurokPartnerFragment
¶
Bases: IsSubscriberMixin
, TemplateView
BillingInfoFormFragment
¶
EbouticCheckout
¶
Bases: CanViewMixin
, UseFragmentsMixin
, DetailView
EbouticPayWithSith
¶
Bases: CanViewMixin
, SingleObjectMixin
, View
EtransactionAutoAnswer
¶
Bases: View