CGM_Public/pretix_original
2
0
Fork 1
mirror of https://github.com/pretix/pretix.git synced 2026-05-06 15:24:02 +00:00
Code Issues Packages Projects Releases Wiki Activity

Spelling corrections

Browse Source
This commit is contained in:
Alexander Brock
2015-07-18 00:47:18 +02:00
parent 2474104d63
commit e81bdbfd92
7 changed files with 26 additions and 23 deletions
Download Patch File Download Diff File Expand all files Collapse all files

2
doc/development/api/general.rst
View File

@@ -11,7 +11,7 @@ HTML head injection
------------------- -------------------
These two signals allow you to put code inside the HTML ``<head>`` tag 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 will get the request as a keyword argument ``request`` and can return plain
HTML. The ``request`` object will have an attribute ``event``. HTML. The ``request`` object will have an attribute ``event``.

2
doc/development/api/plugins.rst
View File

@@ -77,7 +77,7 @@ A working example would be::
The ``AppConfig`` class may implement a property ``compatiblity_errors``, that checks The ``AppConfig`` class may implement a property ``compatiblity_errors``, that checks
whether the pretix installation meets all requirements of the plugin. If so, 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`` 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``, decorator, as it might get called a lot. You can also implement ``compatibility_warnings``,
those will be displayed but not block the plugin execution. those will be displayed but not block the plugin execution.

4
doc/development/api/restriction.rst
View File

@@ -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 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 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 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`` Technically, you won't get ``dict`` objects but ``pretix.base.types.VariationDict``
objects, which behave exactly the same but add some extra methods. objects, which behave exactly the same but add some extra methods.
``context`` ``context``
@@ -217,7 +217,7 @@ Control interface formsets
To make it possible for the event organizer to configure your restriction, there is a 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 '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 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: Currently, the signal comes with only one keyword argument:

21
doc/development/concepts.rst
View File

@@ -26,7 +26,7 @@ Users and events
^^^^^^^^^^^^^^^^ ^^^^^^^^^^^^^^^^
Pretix is all about **events**, which are defined as something happening somewhere. 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 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 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**. 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 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' **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' with **values** 'S', 'M' and 'L' and the **property** 'Color' with **values** 'black'
and 'blue'. and 'blue'.
@@ -79,12 +79,12 @@ include 'Name' or 'age'.
Restrictions 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 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** **restriction** decides whether an variation is available for sale and assign **prices**
to **variations**. There are **restriction types** (pieces of code implementing the to **variations**. There are **restriction types** (pieces of code implementing the
restriction logic) and **restriction instances** (the specific configurations made by 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: 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 * 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 restrictions are being processed in random order (there may not be any assumptions about
the evaluation order). the evaluation order).
* Multiple restriction instances of **different restriction types** are linked with *and*, so * 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. 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*, * 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 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. 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 * 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 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 * 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 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). 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. 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 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. 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 * 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, guarantees you to get your item if you checkout within the validity sell as much items as possible. Moreover, it guarantees the users to get their items if they check out within the validity
period of your lock or pay within the validity period of your order. It does not guarantee you anything 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 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. 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
doc/development/goals.rst
View File

@@ -8,7 +8,7 @@ Technical goals
* Python 3.4 * Python 3.4
* Use Django 1.8+ * 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 * Be fully internationalized, unicode and timezone aware
* Use a fully documented and reproducible setup * Use a fully documented and reproducible setup
* Be fully tested by unit tests * Be fully tested by unit tests
@@ -23,7 +23,7 @@ Next goals
* There is the possibility to send out payment reminders * 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 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 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 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 * 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. * 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) * 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 * 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 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 * There is a flexible concept of payment goals which works well together with the restriction framework mentioned above

8
doc/development/setup.rst
View File

@@ -11,7 +11,9 @@ Just clone our git repository including its submodules::
External Dependencies External Dependencies
--------------------- ---------------------
* Python 3.4 or newer * 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`` * ``git``
* ``lessc`` (Debian package: ``node-less``) * ``lessc`` (Debian package: ``node-less``)
@@ -42,7 +44,7 @@ Then, create the local database::
python manage.py migrate python manage.py migrate
A first user with username ``admin@localhost`` and password ``admin`` will be automatically 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 python make_testdata.py
@@ -92,7 +94,7 @@ for example::
Working with the documentation Working with the documentation
------------------------------ ------------------------------
First, you should install the requirements necessary for building 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:: packages by executing::
cd doc/ cd doc/

4
doc/development/structure.rst
View File

@@ -14,10 +14,10 @@ pretix/
essential to all of pretix's features. essential to all of pretix's features.
control/ control/
This is the django app containing the frontend for organizers. This is the django app containing the front end for organizers.
presale/ 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/
Helpers contain a very few modules providing workarounds for low-level flaws in Helpers contain a very few modules providing workarounds for low-level flaws in