mirror of
https://github.com/pretix/pretix.git
synced 2026-05-03 14:54:04 +00:00
Raphael Michel
@@ -11,7 +11,7 @@ HTML head injection
|
||||
-------------------
|
||||
|
||||
These two signals allow you to put code inside the HTML ``<head>`` tag
|
||||
of every page. One signal is for the frontend, one for the backend. You
|
||||
of every page. One signal is for the front end, one for the back end. You
|
||||
will get the request as a keyword argument ``request`` and can return plain
|
||||
HTML. The ``request`` object will have an attribute ``event``.
|
||||
|
||||
|
||||
@@ -77,7 +77,7 @@ A working example would be::
|
||||
|
||||
The ``AppConfig`` class may implement a property ``compatiblity_errors``, that checks
|
||||
whether the pretix installation meets all requirements of the plugin. If so,
|
||||
it should contian ``None`` or an empty list, otherwise a list of strings containing
|
||||
it should contain ``None`` or an empty list, otherwise a list of strings containing
|
||||
human-readable error messages. We recommend using the ``django.utils.functional.cached_property``
|
||||
decorator, as it might get called a lot. You can also implement ``compatibility_warnings``,
|
||||
those will be displayed but not block the plugin execution.
|
||||
|
||||
@@ -67,7 +67,7 @@ It is sent out with several keyword arguments:
|
||||
exists, it is available in the dictionary via the special key ``'variation'``. If
|
||||
the item does not have any properties, the list will contain exactly one empty
|
||||
dictionary. Please note: this is *not* the list of all possible variations, this is
|
||||
only the list of all variations the frontend likes to determine the status for.
|
||||
only the list of all variations the front end likes to determine the status for.
|
||||
Technically, you won't get ``dict`` objects but ``pretix.base.types.VariationDict``
|
||||
objects, which behave exactly the same but add some extra methods.
|
||||
``context``
|
||||
@@ -217,7 +217,7 @@ Control interface formsets
|
||||
To make it possible for the event organizer to configure your restriction, there is a
|
||||
'Restrictions' page in the item configuration. This page is able to show a formset for
|
||||
each restriction plugin, but *you* are required to create this formset. This is why you
|
||||
should listen to the the ``pretix.control.signals.restriction_formset`` signal.
|
||||
should listen to the ``pretix.control.signals.restriction_formset`` signal.
|
||||
|
||||
Currently, the signal comes with only one keyword argument:
|
||||
|
||||
|
||||
@@ -26,7 +26,7 @@ Users and events
|
||||
^^^^^^^^^^^^^^^^
|
||||
|
||||
Pretix is all about **events**, which are defined as something happening somewhere.
|
||||
Every Event is managed by the **organizer**, an abstract entity running the event.
|
||||
Every event is managed by the **organizer**, an abstract entity running the event.
|
||||
|
||||
Pretix is used by **users**. We want to enable global users who can just login into
|
||||
pretix and buy tickets for as many events as they like but at the same time it
|
||||
@@ -59,7 +59,7 @@ Items and variations
|
||||
|
||||
The purpose of pretix is to sell **items** (which belong to **events**) to **users**.
|
||||
An **item** is a abstract thing, popular examples being event tickets or a piece of
|
||||
merchandise, like 'T-Shirt'. An **item** can have multiple **properties** with multiple
|
||||
merchandise, like 'T-shirt'. An **item** can have multiple **properties** with multiple
|
||||
**values** each. For example, the **item** 'T-Shirt' could have the **property** 'Size'
|
||||
with **values** 'S', 'M' and 'L' and the **property** 'Color' with **values** 'black'
|
||||
and 'blue'.
|
||||
@@ -79,12 +79,12 @@ include 'Name' or 'age'.
|
||||
Restrictions
|
||||
^^^^^^^^^^^^
|
||||
|
||||
The probably most powerful concepts of pretix is the very abstract concept of **restricitons**.
|
||||
The probably most powerful concepts of pretix is the very abstract concept of **restrictions**.
|
||||
We already know that **items** can come in very different **variations**, but a
|
||||
**restriction** decides whether an variation is available for sale and assign **prices**
|
||||
to **variations**. There are **restriction types** (pieces of code implementing the
|
||||
restriction logic) and **restriction instances** (the specific configurations made by the
|
||||
organzier). Although **restrictions** are a very abstract concept which can be used
|
||||
organizer). Although **restrictions** are a very abstract concept which can be used
|
||||
to do nearly anything, there are a few obvious examples:
|
||||
|
||||
* One easy example is a restriction by time, which allows the sale of certain item variations
|
||||
@@ -106,7 +106,7 @@ Any number of **restrictions** can be applied to the whole of a **item** or even
|
||||
* The restrictions are being processed in random order (there may not be any assumptions about
|
||||
the evaluation order).
|
||||
* Multiple restriction instances of **different restriction types** are linked with *and*, so
|
||||
if both a time frame and a restriction by number are applied to an item, the item is only avaliable
|
||||
if both a time frame and a restriction by number are applied to an item, the item is only available
|
||||
for sale during the given time frame *and* only as long as items are available.
|
||||
* Multiple restriction instances of the **same restriction type** are typically linked with *or*,
|
||||
although this is the decision of the restriction logic itself and not mandatory. So for example
|
||||
@@ -127,7 +127,7 @@ special care in the implementation to never sell more tickets than allowed, even
|
||||
about how many of them are still available.
|
||||
* Every time a user places a item in the cart, a **cart lock** is created, reducing the number of
|
||||
available items in the pool by one. The lock is valid for a fixed time (e.g. 30 minutes), but not
|
||||
instantly deleted afther those 30 minutes (we'll get to that).
|
||||
instantly deleted after those 30 minutes (we'll get to that).
|
||||
* Every time a user places a binding order, the lock object is replaced by an **order** which behaves
|
||||
much the same as the lock. It reduces the number of available item and is valid for a fixed time, this
|
||||
time for the configured payment term (e.g. 14 days).
|
||||
@@ -137,9 +137,10 @@ special care in the implementation to never sell more tickets than allowed, even
|
||||
are more cart locks than available tickets and therefore have to remove one of the expired cart locks.
|
||||
However, we do not choose one by random, but keep the surplus in a way that leads to the deletion
|
||||
of the cart lock of the user who tries *last* to use his lock.
|
||||
* The same goes for orders which are not paid within the specified timeframe. This policy allows to
|
||||
sell as much items as possible, guarantees you to get your item if you checkout within the validity
|
||||
period of your lock or pay within the validity period of your order. It does not guarantee you anything
|
||||
* The same goes for orders which are not paid within the specified timeframe. This policy allows the organizer to
|
||||
sell as much items as possible. Moreover, it guarantees the users to get their items if they check out within the validity
|
||||
period of their locks and pay within the validity period of their orders. It does not guarantee them anything
|
||||
any longer, but it tries to be *as tolerant as possible* to users who are paying after their payment
|
||||
period or click checkout after the expiry of their lock.
|
||||
* The same quota can apply to multiple items and one item can be affected by multiple quotas
|
||||
* The same quota can apply to multiple items and one item can be affected by multiple quotas.
|
||||
|
||||
|
||||
@@ -8,7 +8,7 @@ Technical goals
|
||||
|
||||
* Python 3.4
|
||||
* Use Django 1.8+
|
||||
* Be PEP-8 compliant
|
||||
* Be [PEP-8](https://www.python.org/dev/peps/pep-0008/) compliant
|
||||
* Be fully internationalized, unicode and timezone aware
|
||||
* Use a fully documented and reproducible setup
|
||||
* Be fully tested by unit tests
|
||||
@@ -23,7 +23,7 @@ Next goals
|
||||
* There is the possibility to send out payment reminders
|
||||
* The user can download the ticket in PDF form, for which the organizer can upload and customize a template without ever touching a line of code
|
||||
* The system provides a variety of statistics
|
||||
* The system provices export methods for multiple cashdesk/ticket validation systems
|
||||
* The system provides export methods for multiple cashdesk/ticket validation systems
|
||||
|
||||
Achieved goals
|
||||
^^^^^^^^^^^^^^
|
||||
@@ -33,10 +33,10 @@ Achieved goals
|
||||
|
||||
* Tickets are only an instance of an abstract model called items, such that the system can also sell e.g. merchandise
|
||||
* An abstract concept of restriction is used to restrict the selling of tickets, for example by date, by number or by user permissions.
|
||||
* Items can come in multiple flavors (like t-shirt sizes or colors)
|
||||
* Items can come in multiple flavors (like T-shirt sizes or colors)
|
||||
* Items can require additional user input (like attendee names)
|
||||
|
||||
* The software is not only user, but also organizer- and admin-friendly and provides a beautiful and time-saving interface for all admin jobs
|
||||
* The software is not only user-, but also organizer- and admin-friendly and provides a beautiful and time-saving interface for all admin jobs
|
||||
* The software is able to import bank data, at least using CSV files with support for MT940
|
||||
* There is the possibility to add more payment methods later, such as credit card payment, PayPal or even cash
|
||||
* There is a flexible concept of payment goals which works well together with the restriction framework mentioned above
|
||||
|
||||
@@ -11,7 +11,9 @@ Just clone our git repository including its submodules::
|
||||
External Dependencies
|
||||
---------------------
|
||||
* Python 3.4 or newer
|
||||
* ``pip`` for Python 3
|
||||
* ``pip`` for Python 3 (Debian package: ``python3-pip``)
|
||||
* ``pyvenv`` for Python 3 (Debian package: ``python3-venv``)
|
||||
* ``libffi`` (Debian package: ``libffi-dev``)
|
||||
* ``git``
|
||||
* ``lessc`` (Debian package: ``node-less``)
|
||||
|
||||
@@ -42,7 +44,7 @@ Then, create the local database::
|
||||
python manage.py migrate
|
||||
|
||||
A first user with username ``admin@localhost`` and password ``admin`` will be automatically
|
||||
created. If you want to genreate more test data, run::
|
||||
created. If you want to generate more test data, run::
|
||||
|
||||
python make_testdata.py
|
||||
|
||||
@@ -96,7 +98,7 @@ for example::
|
||||
Working with the documentation
|
||||
------------------------------
|
||||
First, you should install the requirements necessary for building the documentation.
|
||||
Make sure you have your virtual python enviroment activated (see above). Then, install the
|
||||
Make sure you have your virtual python environment activated (see above). Then, install the
|
||||
packages by executing::
|
||||
|
||||
cd doc/
|
||||
|
||||
@@ -14,10 +14,10 @@ pretix/
|
||||
essential to all of pretix's features.
|
||||
|
||||
control/
|
||||
This is the django app containing the frontend for organizers.
|
||||
This is the django app containing the front end for organizers.
|
||||
|
||||
presale/
|
||||
This is the django app containing the frontend for users buying tickets.
|
||||
This is the django app containing the front end for users buying tickets.
|
||||
|
||||
helpers/
|
||||
Helpers contain a very few modules providing workarounds for low-level flaws in
|
||||
|
||||
Reference in New Issue
Block a user