CGM_Public/pretix_original
3
0
Fork 1
mirror of https://github.com/pretix/pretix.git synced 2026-08-16 11:46:27 +00:00
Code Issues Packages Projects Releases Wiki Activity

Fixed minor documentation errors and mistakes (#151)

Browse Source
This commit is contained in:
Tobias Kunze
2016-07-14 20:01:38 +02:00
committed by Raphael Michel
parent f779b70deb
commit bfc721978d
41 changed files with 231 additions and 208 deletions
Download Patch File Download Diff File Expand all files Collapse all files
doc/development/concepts.rst
+16 -18
View File
@@ -19,7 +19,7 @@ The project pretix is split into several components. The main three of them are:
create and manage their events, items, orders and tickets.
**pretix.presale**
Pretixpresale is the ticket-shop itself, containing all the parts visible to the
Pretixpresale is the ticket-shop itself, containing all of the parts visible to the
end user.
Users and events
@@ -28,25 +28,24 @@ 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.
Pretix has a concept of **users** that is used for all the people who have to log
in to the control panel to manage one or more events. No user is required to place an
order.
Pretix has a concept of **users** that is used for all people who have to log in to the
control panel to manage one or more events. No user is required to place an order.
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
The purpose of pretix is to sell **items** (which belong to **events**) to **users**.
An **item** is a abstract thing, popular examples being an event ticket or a piece of
merchandise, like 'T-shirt'. An **item** can have multiple **variations**. For example,
the **item** 'T-Shirt' could have the **variations** S', 'M' and 'L'.
the **item** 'T-Shirt' could have the **variations** 'S', 'M' and 'L'.
Questions
^^^^^^^^^
An item can be extended using **questions**. Questions enable items to be extended by
additional information which can be entered by the user. Examples of possible questions
include 'Name' or 'age'.
include 'name' or 'age'.
Restriction by number
"""""""""""""""""""""
@@ -59,17 +58,16 @@ special care in the implementation to never sell more tickets than allowed, even
* Every time a user places a item in the cart, a **cart position** is created, reducing the number of
available items in the pool by one. The position is valid for a fixed time (e.g. 30 minutes), but not
instantly deleted after those 30 minutes (we'll get to that).
* Every time a user places a binding order, the position object is replaced by an **order position** which behaves
much the same as the cart position. 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).
* Every time a user places a binding order, the **cart position** object is replaced by an **order position**
object which behaves much the same as the cart position. It reduces the number of available items and is valid
for a fixed time, this time for the configured payment term (e.g. 14 days).
* If the order is being paid, the **order** becomes permanent.
* Once there are no available tickets left and user A wants to buy a ticket, he can do so, as long as
there are *expired* cart position in the system. In this case, user A gets a new cart position, so that there
are more cart position than available tickets and therefore have to remove one of the expired cart positions.
However, we do not choose one by random, but keep the surplus in a way that leads to the deletion
of the cart position f the user who tries *last* to use his cart position.
* 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
* Once there are no available tickets left and user A wants to buy a ticket, they can do so, as long as
there are *expired* cart position in the system. In this case, user A gets a new cart position. Now there are
more cart positions than available tickets and therefore we have to remove one of the expired cart positions.
We will choose to delete the cart position of the user who tries *last* to use his cart position.
* The same goes for orders which are not paid within the configured time frame. This policy allows the organizer to
sell as many items as possible. Moreover, it guarantees the users to get their items if they check out within the validity
period of their positions 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 position.