Prepare for new docs, remove user docs as they move to own repo (#4819)
71
doc/_templates/index.html
vendored
@@ -1,43 +1,16 @@
|
||||
{% extends "layout.html" %}
|
||||
{% set title = 'Overview' %}
|
||||
{% block body %}
|
||||
<h1>Welcome to pretix' documentation!</h1>
|
||||
<h1>Welcome to our developer documentation!</h1>
|
||||
<p>
|
||||
We work hard to make this website contain all information that you need to use, run, understand, and improve
|
||||
pretix. Of course, this documentation will never be perfect or complete, but if there is anything unclear
|
||||
We work hard to make this website contain all information that you need to work with our API or source code.
|
||||
Of course, this documentation will never be perfect or complete, but if there is anything unclear
|
||||
or anything specific that you miss here, that's a bug and we'd be happy if you'd
|
||||
<a href="https://github.com/pretix/pretix/issues/new">let us know</a>.
|
||||
</p>
|
||||
|
||||
<h2>Documentation structure</h2>
|
||||
<h2>What you can find here</h2>
|
||||
|
||||
<div class="sectionbox">
|
||||
<div class="icon">
|
||||
<a href="user/index.html">
|
||||
<span class="fa fa-user fa-fw"></span>
|
||||
</a>
|
||||
</div>
|
||||
<div class="text">
|
||||
<a href="user/index.html">
|
||||
<strong>User Guide</strong>
|
||||
</a>
|
||||
<p>Go here to find information on how to configure and use pretix as an event organizer.</p>
|
||||
</div>
|
||||
</div>
|
||||
<div class="sectionbox">
|
||||
<div class="icon">
|
||||
<a href="admin/index.html">
|
||||
<span class="fa fa-server fa-fw"></span>
|
||||
</a>
|
||||
</div>
|
||||
<div class="text">
|
||||
<a href="admin/index.html">
|
||||
<strong>Administrator docs</strong>
|
||||
</a>
|
||||
<p>Find out how to install pretix on your own server and how to maintain an installation of pretix.</p>
|
||||
</div>
|
||||
</div>
|
||||
<div class="clearfix"></div>
|
||||
<div class="sectionbox">
|
||||
<div class="icon">
|
||||
<a href="api/index.html">
|
||||
@@ -69,30 +42,33 @@
|
||||
</div>
|
||||
</div>
|
||||
<div class="clearfix"></div>
|
||||
|
||||
|
||||
<h2>Other sources of documentation</h2>
|
||||
<div class="sectionbox">
|
||||
<div class="icon">
|
||||
<a href="plugins/index.html">
|
||||
<span class="fa fa-puzzle-piece fa-fw"></span>
|
||||
<a href="https://docs.pretix.eu" target="_blank">
|
||||
<span class="fa fa-user fa-fw"></span>
|
||||
</a>
|
||||
</div>
|
||||
<div class="text">
|
||||
<a href="plugins/index.html">
|
||||
<strong>Plugin docs</strong>
|
||||
<a href="https://docs.pretix.eu" target="_blank">
|
||||
<strong>User docs</strong>
|
||||
</a>
|
||||
<p>Documentation and details on plugins that ship with pretix or are officially supported.</p>
|
||||
<p>Go here to find information on how to configure and use pretix as an event organizer.</p>
|
||||
</div>
|
||||
</div>
|
||||
<div class="sectionbox">
|
||||
<div class="icon">
|
||||
<a href="contents.html">
|
||||
<span class="fa fa-list fa-fw"></span>
|
||||
<a href="https://docs.pretix.eu/self-hosting/">
|
||||
<span class="fa fa-server fa-fw"></span>
|
||||
</a>
|
||||
</div>
|
||||
<div class="text">
|
||||
<a href="contents.html">
|
||||
<strong>Table of contents</strong>
|
||||
<a href="https://docs.pretix.eu/self-hosting/">
|
||||
<strong>Administrator docs</strong>
|
||||
</a>
|
||||
<p>Detailled overview of everything contained in this documentation.</p>
|
||||
<p>Find out how to install pretix on your own server and how to maintain an installation of pretix.</p>
|
||||
</div>
|
||||
</div>
|
||||
<div class="clearfix"></div>
|
||||
@@ -142,19 +118,6 @@
|
||||
general news on pretix as a project.</p>
|
||||
</div>
|
||||
</div>
|
||||
<div class="sectionbox">
|
||||
<div class="icon">
|
||||
<a href="https://twitter.com/pretixeu" target="_blank">
|
||||
<span class="fa fa-twitter fa-fw"></span>
|
||||
</a>
|
||||
</div>
|
||||
<div class="text">
|
||||
<a href="https://twitter.com/pretixeu" target="_blank">
|
||||
<strong>Twitter</strong>
|
||||
</a>
|
||||
<p>Keep in touch and stay up to date by following our project account on Twitter.</p>
|
||||
</div>
|
||||
</div>
|
||||
<div class="clearfix"></div>
|
||||
|
||||
{% endblock %}
|
||||
1
doc/_themes/pretix_theme/layout.html
vendored
@@ -115,6 +115,7 @@
|
||||
{%- if logo or logo_url %}
|
||||
<img src="{{ _logo_url }}" class="logo" alt="{{ _('Logo') }}"/>
|
||||
{%- endif %}
|
||||
Developer Documentation
|
||||
</a>
|
||||
|
||||
{% include "searchbox.html" %}
|
||||
|
||||
@@ -5183,7 +5183,7 @@ div[class^='highlight'] pre {
|
||||
|
||||
.wy-side-nav-search > a img.logo, .wy-side-nav-search .wy-dropdown > a img.logo {
|
||||
display: block;
|
||||
margin: 0 auto;
|
||||
margin: 0 auto 10px;
|
||||
height: 50px;
|
||||
width: auto;
|
||||
border-radius: 0;
|
||||
|
||||
@@ -1,548 +0,0 @@
|
||||
.. highlight:: ini
|
||||
|
||||
.. _`config`:
|
||||
|
||||
.. spelling:word-list:: Galera
|
||||
|
||||
Configuration file
|
||||
==================
|
||||
|
||||
Pretix reads its configuration from a configuration file. It tries to find this file
|
||||
at the following locations. It will try to read the file from the specified paths in
|
||||
the following order. The file that is found *last* will override the settings from
|
||||
the files found before.
|
||||
|
||||
1. ``PRETIX_CONFIG_FILE`` environment variable
|
||||
2. ``/etc/pretix/pretix.cfg``
|
||||
3. ``~/.pretix.cfg``
|
||||
4. ``pretix.cfg`` in the current working directory
|
||||
|
||||
The file is expected to be in the INI format as specified in the `Python documentation`_.
|
||||
|
||||
The config file may contain the following sections (all settings are optional and have
|
||||
default values). We suggest that you start from the examples given in one of the
|
||||
installation tutorials.
|
||||
|
||||
.. note::
|
||||
|
||||
The configuration file is the recommended way to configure pretix. However, you can
|
||||
also set them through environment variables. In this case, the syntax is
|
||||
``PRETIX_SECTION_CONFIG``. For example, to configure the setting ``password_reset``
|
||||
from the ``[pretix]`` section, set ``PRETIX_PRETIX_PASSWORD_RESET=off`` in your
|
||||
environment.
|
||||
|
||||
pretix settings
|
||||
---------------
|
||||
|
||||
Example::
|
||||
|
||||
[pretix]
|
||||
instance_name=pretix.de
|
||||
url=http://localhost
|
||||
currency=EUR
|
||||
datadir=/data
|
||||
plugins_default=pretix.plugins.sendmail,pretix.plugins.statistics
|
||||
|
||||
``instance_name``
|
||||
The name of this installation. Default: ``pretix.de``
|
||||
|
||||
``url``
|
||||
The installation's full URL, without a trailing slash.
|
||||
|
||||
``currency``
|
||||
The default currency as a three-letter code. Defaults to ``EUR``.
|
||||
|
||||
``cachedir``
|
||||
The local path to a directory where temporary files will be stored.
|
||||
Defaults to the ``cache`` directory below the ``datadir``.
|
||||
|
||||
``datadir``
|
||||
The local path to a data directory that will be used for storing user uploads and similar
|
||||
data. Defaults to the value of the environment variable ``DATA_DIR`` or ``data``.
|
||||
|
||||
``logdir``
|
||||
The local path to a directory where log files will be stored.
|
||||
Defaults to the ``logs`` directory below the ``datadir``.
|
||||
|
||||
``plugins_default``
|
||||
A comma-separated list of plugins that are enabled by default for all new events.
|
||||
Defaults to ``pretix.plugins.sendmail,pretix.plugins.statistics``.
|
||||
|
||||
``plugins_exclude``
|
||||
A comma-separated list of plugins that are not available even though they are installed.
|
||||
Defaults to an empty string.
|
||||
|
||||
``plugins_show_meta``
|
||||
Whether to show authors and versions of plugins, defaults to ``on``.
|
||||
|
||||
``auth_backends``
|
||||
A comma-separated list of available auth backends. Defaults to ``pretix.base.auth.NativeAuthBackend``.
|
||||
|
||||
``registration``
|
||||
Enables or disables the registration of new admin users. Defaults to ``off``.
|
||||
|
||||
``password_reset``
|
||||
Enables or disables password reset. Defaults to ``on``.
|
||||
|
||||
``long_sessions``
|
||||
Enables or disables the "keep me logged in" button. Defaults to ``on``.
|
||||
|
||||
``ecb_rates``
|
||||
By default, pretix periodically downloads currency rates from the European Central Bank as well as other authorities
|
||||
that are used to print tax amounts in the customer currency on invoices for some currencies. Set to ``off`` to
|
||||
disable this feature. Defaults to ``on``.
|
||||
|
||||
``audit_comments``
|
||||
Enables or disables nagging staff users for leaving comments on their sessions for auditability.
|
||||
Defaults to ``off``.
|
||||
|
||||
``obligatory_2fa``
|
||||
Enables or disables obligatory usage of two-factor authentication for users of the pretix backend.
|
||||
Can be ``True`` to make two-factor authentication obligatory for all users or ``staff`` to make it only
|
||||
obligatory to users with admin permissions. Defaults to ``False``.
|
||||
|
||||
``trust_x_forwarded_for``
|
||||
Specifies whether the ``X-Forwarded-For`` header can be trusted. Only set to ``on`` if you have a reverse
|
||||
proxy that actively removes and re-adds the header to make sure the correct client IP is the first value.
|
||||
Defaults to ``off``.
|
||||
|
||||
``trust_x_forwarded_proto``
|
||||
Specifies whether the ``X-Forwarded-Proto`` header can be trusted. Only set to ``on`` if you have a reverse
|
||||
proxy that actively removes and re-adds the header to make sure the correct value is set.
|
||||
Defaults to ``off``.
|
||||
|
||||
``trust_x_forwarded_host``
|
||||
Specifies whether the ``X-Forwarded-Host`` header can be trusted. Only set to ``on`` if you have a reverse
|
||||
proxy that actively removes and re-adds the header to make sure the correct value is set.
|
||||
Defaults to ``off``.
|
||||
|
||||
``csp_log``
|
||||
Log violations of the Content Security Policy (CSP). Defaults to ``on``.
|
||||
|
||||
``csp_additional_header``
|
||||
Specifies a CSP header that will be **merged** with pretix's default header. For example, if you set this
|
||||
to ``script-src https://mycdn.com``, pretix will add ``https://mycdn.com`` as an **additional** allowed source
|
||||
to all CSP headers. Empty by default.
|
||||
|
||||
``loglevel``
|
||||
Set console and file log level (``DEBUG``, ``INFO``, ``WARNING``, ``ERROR`` or ``CRITICAL``). Defaults to ``INFO``.
|
||||
|
||||
``request_id_header``
|
||||
Specifies the name of a header that should be used for logging request IDs. Off by default.
|
||||
|
||||
Locale settings
|
||||
---------------
|
||||
|
||||
Example::
|
||||
|
||||
[locale]
|
||||
default=de
|
||||
timezone=Europe/Berlin
|
||||
|
||||
``default``
|
||||
The system's default locale. Default: ``en``
|
||||
|
||||
``timezone``
|
||||
The system's default timezone as a ``pytz`` name. Default: ``UTC``
|
||||
|
||||
Database settings
|
||||
-----------------
|
||||
|
||||
Example::
|
||||
|
||||
[database]
|
||||
backend=postgresql
|
||||
name=pretix
|
||||
user=pretix
|
||||
password=abcd
|
||||
host=localhost
|
||||
port=3306
|
||||
advisory_lock_index=1
|
||||
disable_server_side_cursors=0
|
||||
sslmode=require
|
||||
sslrootcert=/etc/pretix/postgresql-ca.crt
|
||||
sslcert=/etc/pretix/postgresql-client-crt.crt
|
||||
sslkey=/etc/pretix/postgresql-client-key.key
|
||||
|
||||
``backend``
|
||||
One of ``sqlite3`` and ``postgresql``.
|
||||
Default: ``sqlite3``.
|
||||
|
||||
``name``
|
||||
The database's name. Default: ``db.sqlite3``.
|
||||
|
||||
``user``, ``password``, ``host``, ``port``
|
||||
Connection details for the database connection. Empty by default.
|
||||
|
||||
``advisory_lock_index``
|
||||
On PostgreSQL, pretix uses the "advisory lock" feature. However, advisory locks use a server-wide name space and
|
||||
and are not scoped to a specific database. If you run multiple pretix applications with the same PostgreSQL server,
|
||||
you should set separate values for this setting (integers up to 256).
|
||||
|
||||
``disable_server_side_cursors``
|
||||
On PostgreSQL pretix might use server side cursors for certain operations. This is generally fine but will break in
|
||||
specific circumstances, for example when connecting to PostgreSQL through a PGBouncer configured with a transaction
|
||||
pool mode. Off by default (i.e. by default server side cursors will be used).
|
||||
|
||||
``sslmode``, ``sslrootcert``
|
||||
Connection TLS details for the PostgreSQL database connection. Possible values of ``sslmode`` are ``disable``, ``allow``, ``prefer``, ``require``, ``verify-ca``, and ``verify-full``. ``sslrootcert`` should be the accessible path of the ca certificate. Both values are empty by default.
|
||||
|
||||
``sslcert``, ``sslkey``
|
||||
Connection mTLS details for the PostgreSQL database connection. It's also necessary to specify ``sslmode`` and ``sslrootcert`` parameters, please check the correct values from the TLS part. ``sslcert`` should be the accessible path of the client certificate. ``sslkey`` should be the accessible path of the client key. All values are empty by default.
|
||||
|
||||
.. _`config-replica`:
|
||||
|
||||
Database replica settings
|
||||
-------------------------
|
||||
|
||||
If you use a replicated database setup, pretix expects that the default database connection always points to the primary database node.
|
||||
Routing read queries to a replica on database layer is **strongly** discouraged since this can lead to inaccurate such as more tickets
|
||||
being sold than are actually available.
|
||||
|
||||
However, pretix can still make use of a database replica to keep some expensive queries with that can tolerate some latency from your
|
||||
primary database, such as backend search queries. The ``replica`` configuration section can have the same settings as the ``database``
|
||||
section (except for the ``backend`` setting) and will default back to the ``database`` settings for all values that are not given. This
|
||||
way, you just need to specify the settings that are different for the replica.
|
||||
|
||||
Example::
|
||||
|
||||
[replica]
|
||||
host=192.168.0.2
|
||||
|
||||
.. _`config-urls`:
|
||||
|
||||
URLs
|
||||
----
|
||||
|
||||
Example::
|
||||
|
||||
[urls]
|
||||
media=/media/
|
||||
static=/static/
|
||||
|
||||
``media``
|
||||
The URL to be used to serve user-uploaded content. You should not need to modify
|
||||
this. Default: ``/media/``
|
||||
|
||||
``static``
|
||||
The URL to be used to serve static files. You should not need to modify
|
||||
this. Default: ``/static/``
|
||||
|
||||
.. _`mail-settings`:
|
||||
|
||||
Email
|
||||
-----
|
||||
|
||||
Example::
|
||||
|
||||
[mail]
|
||||
from=hello@localhost
|
||||
host=127.0.0.71
|
||||
user=pretix
|
||||
password=foobar
|
||||
port=1025
|
||||
tls=on
|
||||
ssl=off
|
||||
|
||||
``host``, ``port``
|
||||
The SMTP Host to connect to. Defaults to ``localhost`` and ``25``.
|
||||
|
||||
``user``, ``password``
|
||||
The SMTP user data to use for the connection. Empty by default.
|
||||
|
||||
``tls``, ``ssl``
|
||||
Use STARTTLS or SSL for the SMTP connection. Off by default.
|
||||
|
||||
``from``
|
||||
The email address to set as ``From`` header in outgoing emails by the system.
|
||||
Default: ``pretix@localhost``
|
||||
|
||||
``from_notifications``
|
||||
The email address to set as ``From`` header in admin notification emails by the system.
|
||||
Defaults to the value of ``from``.
|
||||
|
||||
``from_organizers``
|
||||
The email address to set as ``From`` header in outgoing emails by the system sent on behalf of organizers.
|
||||
Defaults to the value of ``from``.
|
||||
|
||||
``custom_sender_verification_required``
|
||||
If this is on (the default), organizers need to verify email addresses they want to use as senders in their event.
|
||||
|
||||
``custom_sender_spf_string``
|
||||
If this is set to a valid SPF string, pretix will show a warning if organizers use a sender address from a domain
|
||||
that does not include this value.
|
||||
|
||||
``custom_smtp_allow_private_networks``
|
||||
If this is off (the default), custom SMTP servers cannot be private network addresses.
|
||||
|
||||
``admins``
|
||||
Comma-separated list of email addresses that should receive a report about every error code 500 thrown by pretix.
|
||||
|
||||
.. _`django-settings`:
|
||||
|
||||
Django settings
|
||||
---------------
|
||||
|
||||
Example::
|
||||
|
||||
[django]
|
||||
secret=j1kjps5a5&4ilpn912s7a1!e2h!duz^i3&idu@_907s$wrz@x-
|
||||
debug=off
|
||||
passwords_argon2=on
|
||||
|
||||
``secret``
|
||||
The secret to be used by Django for signing and verification purposes. If this
|
||||
setting is not provided, pretix will generate a random secret on the first start
|
||||
and will store it in the filesystem for later usage.
|
||||
|
||||
``secret_fallback0`` ... ``secret_fallback9``
|
||||
Prior versions of the secret to be used by Django for signing and verification purposes that will still
|
||||
be accepted but no longer be used for new signing.
|
||||
|
||||
``debug``
|
||||
Whether or not to run in debug mode. Default is ``False``.
|
||||
|
||||
.. WARNING:: Never set this to ``True`` in production!
|
||||
|
||||
``passwords_argon``
|
||||
Use the ``argon2`` algorithm for password hashing. Disable on systems with a small number of CPU cores (currently
|
||||
less than 8).
|
||||
|
||||
``profile``
|
||||
Enable code profiling for a random subset of requests. Disabled by default, see
|
||||
:ref:`perf-monitoring` for details.
|
||||
|
||||
.. _`metrics-settings`:
|
||||
|
||||
Metrics
|
||||
-------
|
||||
|
||||
If you want to fetch internally collected prometheus-style metrics you need to configure the credentials for the
|
||||
metrics endpoint and enable it::
|
||||
|
||||
[metrics]
|
||||
enabled=true
|
||||
user=your_user
|
||||
passphrase=mysupersecretpassphrase
|
||||
|
||||
Currently, metrics-collection requires a redis server to be available.
|
||||
|
||||
|
||||
Memcached
|
||||
---------
|
||||
|
||||
You can use an existing memcached server as pretix's caching backend::
|
||||
|
||||
[memcached]
|
||||
location=127.0.0.1:11211
|
||||
|
||||
``location``
|
||||
The location of memcached, either a host:port combination or a socket file.
|
||||
|
||||
If no memcached is configured, pretix will use redis for caching. If neither is configured, pretix will not use any caching.
|
||||
|
||||
.. note:: If you use memcached and you deploy pretix across multiple servers, you should use *one*
|
||||
shared memcached instance, not multiple ones, because cache invalidations would not be
|
||||
propagated otherwise.
|
||||
|
||||
Redis
|
||||
-----
|
||||
|
||||
If a redis server is configured, pretix can use it for locking, caching and session storage
|
||||
to speed up various operations::
|
||||
|
||||
[redis]
|
||||
location=redis://127.0.0.1:6379/1
|
||||
sessions=false
|
||||
sentinels=[
|
||||
["sentinel_host_1", 26379],
|
||||
["sentinel_host_2", 26379],
|
||||
["sentinel_host_3", 26379]
|
||||
]
|
||||
password=password
|
||||
ssl_cert_reqs=required
|
||||
ssl_ca_certs=/etc/pretix/redis-ca.pem
|
||||
ssl_keyfile=/etc/pretix/redis-client-crt.pem
|
||||
ssl_certfile=/etc/pretix/redis-client-key.key
|
||||
|
||||
``location``
|
||||
The location of redis, as a URL of the form ``redis://[:password]@localhost:6379/0``
|
||||
or ``unix://[:password]@/path/to/socket.sock?db=0``
|
||||
|
||||
``sessions``
|
||||
When this is set to ``True``, redis will be used as the session storage.
|
||||
|
||||
``sentinels``
|
||||
Configures redis sentinels to use.
|
||||
If you don't want to use redis sentinels, you should omit this option.
|
||||
If this is set, redis via sentinels will be used instead of plain redis.
|
||||
In this case the location should be of the form ``redis://my_master/0``.
|
||||
The ``sentinels`` variable should be a json serialized list of sentinels,
|
||||
each being a list with the two elements hostname and port.
|
||||
You cannot provide a password within the location when using sentinels.
|
||||
Note that the configuration format requires you to either place the entire
|
||||
value on one line or make sure all values are indented by at least one space.
|
||||
|
||||
``password``
|
||||
If your redis setup doesn't require a password or you already specified it in the location you can omit this option.
|
||||
If this is set it will be passed to redis as the connection option PASSWORD.
|
||||
|
||||
``ssl_cert_reqs``
|
||||
If this is set it will be passed to redis as the connection option ``SSL_CERT_REQS``.
|
||||
Possible values are ``none``, ``optional``, and ``required``.
|
||||
|
||||
``ssl_ca_certs``
|
||||
If your redis setup doesn't require TLS you can omit this option.
|
||||
If this is set it will be passed to redis as the connection option ``SSL_CA_CERTS``. Possible value is the ca path.
|
||||
|
||||
``ssl_keyfile``
|
||||
If your redis setup doesn't require mTLS you can omit this option.
|
||||
If this is set it will be passed to redis as the connection option ``SSL_KEYFILE``. Possible value is the keyfile path.
|
||||
|
||||
``ssl_certfile``
|
||||
If your redis setup doesn't require mTLS you can omit this option.
|
||||
If this is set it will be passed to redis as the connection option ``SSL_CERTFILE``. Possible value is the certfile path.
|
||||
|
||||
If redis is not configured, pretix will store sessions and locks in the database. If memcached
|
||||
is configured, memcached will be used for caching instead of redis.
|
||||
|
||||
Translations
|
||||
------------
|
||||
|
||||
pretix comes with a number of translations. All languages are enabled by default. If you want to limit
|
||||
the languages available in your installation, you can enable a set of languages like this::
|
||||
|
||||
[languages]
|
||||
enabled=en,de
|
||||
|
||||
Some of the languages them are marked as "incubating", which means
|
||||
they can usually only be selected in development mode. If you want to use them nevertheless, you
|
||||
can activate them like this::
|
||||
|
||||
[languages]
|
||||
allow_incubating=pt-br,da
|
||||
|
||||
You can also tell pretix about additional paths where it will search for translations::
|
||||
|
||||
[languages]
|
||||
path=/path/to/my/translations
|
||||
|
||||
For a given language (e.g. ``pt-br``), pretix will then look in the
|
||||
specific sub-folder, e.g. ``/path/to/my/translations/pt_BR/LC_MESSAGES/django.po``.
|
||||
|
||||
Celery task queue
|
||||
-----------------
|
||||
|
||||
For processing long-running tasks asynchronously, pretix requires the celery task queue.
|
||||
For communication between the web server and the task workers in both direction, a messaging
|
||||
queue and a result backend is needed. You can use a redis database for both directions, or
|
||||
an AMQP server (e.g. RabbitMQ) as a broker and redis or your database as a result backend::
|
||||
|
||||
[celery]
|
||||
broker=amqp://guest:guest@localhost:5672//
|
||||
backend=redis://localhost/0
|
||||
broker_transport_options="{}"
|
||||
backend_transport_options="{}"
|
||||
|
||||
RabbitMQ might be the better choice if you have a complex, multi-server, high-performance setup,
|
||||
but as you already should have a redis instance ready for session and lock storage, we recommend
|
||||
redis for convenience. See the `Celery documentation`_ for more details.
|
||||
|
||||
The two ``transport_options`` entries can be omitted in most cases.
|
||||
If they are present they need to be a valid JSON dictionary.
|
||||
For possible entries in that dictionary see the `Celery documentation`_.
|
||||
|
||||
It is possible the use Redis with TLS/mTLS for the broker or the backend. To do so, it is necessary to specify the TLS identifier ``rediss``, the ssl mode ``ssl_cert_reqs`` and optionally specify the CA (TLS) ``ssl_ca_certs``, cert ``ssl_certfile`` and key ``ssl_keyfile`` (mTLS) path as encoded string. the following uri describes the format and possible parameters ``rediss://0.0.0.0:6379/1?ssl_cert_reqs=required&ssl_ca_certs=%2Fetc%2Fpretix%2Fredis-ca.pem&ssl_certfile=%2Fetc%2Fpretix%2Fredis-client-crt.pem&ssl_keyfile=%2Fetc%2Fpretix%2Fredis-client-key.key``
|
||||
|
||||
To use redis with sentinels set the broker or backend to ``sentinel://sentinel_host_1:26379;sentinel_host_2:26379/0``
|
||||
and the respective transport_options to ``{"master_name":"mymaster"}``.
|
||||
If your redis instances behind the sentinel have a password use ``sentinel://:my_password@sentinel_host_1:26379;sentinel_host_2:26379/0``.
|
||||
If your redis sentinels themselves have a password set the transport_options to ``{"master_name":"mymaster","sentinel_kwargs":{"password":"my_password"}}``.
|
||||
|
||||
Sentry
|
||||
------
|
||||
|
||||
pretix has native support for sentry, a tool that you can use to track errors in the
|
||||
application. If you want to use sentry, you need to set a DSN in the configuration file::
|
||||
|
||||
[sentry]
|
||||
dsn=https://<key>:<secret>@sentry.io/<project>
|
||||
traces_sample_rate=0.5
|
||||
traces_sample_token=xyz
|
||||
|
||||
``dsn``
|
||||
You will be given this value by your sentry installation.
|
||||
|
||||
``traces_sample_rate``
|
||||
Sample rate for performance monitoring.
|
||||
|
||||
``traces_sample_token``
|
||||
If this token is found in a query string, a trace will always be sampled.
|
||||
|
||||
|
||||
Caching
|
||||
-------
|
||||
|
||||
You can adjust some caching settings to control how much storage pretix uses::
|
||||
|
||||
[cache]
|
||||
tickets=48 ; Number of hours tickets (PDF, passbook, …) are cached
|
||||
|
||||
|
||||
Secret length
|
||||
-------------
|
||||
|
||||
If you are really paranoid, you can increase the length of random strings pretix uses in
|
||||
various places like order codes, secrets in the ticket QR codes, etc. Example::
|
||||
|
||||
[entropy]
|
||||
; Order code needs to be < 16 characters, default is 5
|
||||
order_code=5
|
||||
; Ticket secret needs to be < 64 characters, default is 32
|
||||
ticket_secret=32
|
||||
; Voucher code needs to be < 255 characters, default is 16
|
||||
voucher_code=16
|
||||
|
||||
External tools
|
||||
--------------
|
||||
|
||||
pretix can make use of some external tools if they are installed. Currently, they are all optional. Example::
|
||||
|
||||
[tools]
|
||||
pdftk=/usr/bin/pdftk
|
||||
|
||||
.. _Python documentation: https://docs.python.org/3/library/configparser.html?highlight=configparser#supported-ini-file-structure
|
||||
.. _Celery documentation: http://docs.celeryproject.org/en/latest/userguide/configuration.html
|
||||
|
||||
Maximum upload file sizes
|
||||
-------------------------
|
||||
|
||||
You can configure the maximum file size for uploading various files::
|
||||
|
||||
[pretix_file_upload]
|
||||
; Max upload size for images in MiB, defaults to 10 MiB
|
||||
max_size_image = 12
|
||||
; Max upload size for favicons in MiB, defaults to 1 MiB
|
||||
max_size_favicon = 2
|
||||
; Max upload size for email attachments of manually sent emails in MiB, defaults to 10 MiB
|
||||
max_size_email_attachment = 15
|
||||
; Max upload size for email attachments of automatically sent emails in MiB, defaults to 1 MiB
|
||||
max_size_email_auto_attachment = 2
|
||||
; Max upload size for other files in MiB, defaults to 10 MiB
|
||||
; This includes all file upload type order questions
|
||||
max_size_other = 100
|
||||
|
||||
|
||||
GeoIP
|
||||
-----
|
||||
|
||||
pretix can optionally make use of a GeoIP database for some features. It needs a file in ``mmdb`` format, for example
|
||||
`GeoLite2`_ or `GeoAcumen`_::
|
||||
|
||||
[geoip]
|
||||
path=/var/geoipdata/
|
||||
filename_country=GeoLite2-Country.mmdb
|
||||
|
||||
|
||||
.. _GeoAcumen: https://github.com/geoacumen/geoacumen-country
|
||||
.. _GeoLite2: https://dev.maxmind.com/geoip/geolite2-free-geolocation-data
|
||||
@@ -1,40 +0,0 @@
|
||||
.. _`admin-errors`:
|
||||
|
||||
Dealing with errors
|
||||
===================
|
||||
|
||||
If you encounter an error in pretix, please follow the following steps to debug it:
|
||||
|
||||
* If the error message is shown on a **white page** and the last line of the error includes "nginx", the error is not with pretix
|
||||
directly but with your nginx webserver. This might mean that pretix is not running, but it could also be something else.
|
||||
Please first check your nginx error log. The default location is ``/var/log/nginx/error.log``.
|
||||
|
||||
* If it turns out pretix is not running, check the output of ``docker logs pretix`` for a docker installation and
|
||||
``journalctl -u pretix-web.service`` for a manual installation.
|
||||
|
||||
* If the error message is an "**Internal Server Error**" in purple pretix design, please check pretix' log file which by default is at
|
||||
``/var/pretix-data/logs/pretix.log`` if you installed with docker and ``/var/pretix/data/logs/pretix.log`` otherwise. If you don't
|
||||
know how to interpret it, open a discussion on GitHub with the relevant parts of the log file.
|
||||
|
||||
* If the error message includes ``/usr/bin/env: ‘node’: No such file or directory``, you forgot to install ``node.js``
|
||||
|
||||
* If the error message includes ``OfflineGenerationError``, you might have forgot to run the ``rebuild`` step after a pretix update
|
||||
or plugin installation.
|
||||
|
||||
* If the error message mentions your database server or redis server, make sure these are running and accessible.
|
||||
|
||||
* If pretix loads fine but certain actions (creating carts, orders, or exports, downloading tickets, sending emails) **take forever**,
|
||||
``pretix-worker`` is not running. Check the output of ``docker logs pretix`` for a docker installation and
|
||||
``journalctl -u pretix-worker.service`` for a manual installation.
|
||||
|
||||
* If the page loads but all **styles are missing**, you probably forgot to update your nginx configuration file after an upgrade of your
|
||||
operating system's python version.
|
||||
|
||||
|
||||
If you are unable to debug the issue any further, please open a **discussion** on GitHub in our `Q&A Forum`_. Do **not** open an issue
|
||||
right away, since most things turn out not to be a bug in pretix but a mistake in your server configuration. Make sure to include
|
||||
relevant log excerpts in your question.
|
||||
|
||||
If you're a pretix Enterprise customer, you can also reach out to support@pretix.eu with your issue right away.
|
||||
|
||||
.. _Q&A Forum: https://github.com/pretix/pretix/discussions/categories/q-a
|
||||
@@ -1,18 +0,0 @@
|
||||
.. _`admindocs`:
|
||||
|
||||
Administrator documentation
|
||||
===========================
|
||||
|
||||
This documentation is for everyone who wants to install pretix on a server.
|
||||
|
||||
.. toctree::
|
||||
:maxdepth: 2
|
||||
|
||||
installation/index
|
||||
updates
|
||||
config
|
||||
maintainance
|
||||
scaling
|
||||
errors
|
||||
mysql2postgres
|
||||
indexes
|
||||
@@ -1,83 +0,0 @@
|
||||
Additional database indices
|
||||
===========================
|
||||
|
||||
If you have a large pretix database, some features such as search for orders or events might turn pretty slow.
|
||||
For PostgreSQL, we have compiled a list of additional database indexes that you can add to speed things up.
|
||||
Just like any index, they in turn make write operations insignificantly slower and cause the database to use
|
||||
more disk space.
|
||||
|
||||
The indexes aren't automatically created by pretix since Django does not allow us to do so only on PostgreSQL
|
||||
(and they won't work on other databases). Also, they're really not necessary if you're not having tens of
|
||||
thousands of records in your database.
|
||||
|
||||
However, this also means they won't automatically adapt if some of the referred fields change in future updates of pretix
|
||||
and you might need to re-check this page and change them manually.
|
||||
|
||||
Here is the currently recommended set of commands::
|
||||
|
||||
CREATE EXTENSION pg_trgm;
|
||||
|
||||
CREATE INDEX CONCURRENTLY pretix_addidx_event_slug
|
||||
ON pretixbase_event
|
||||
USING gin (upper("slug") gin_trgm_ops);
|
||||
CREATE INDEX CONCURRENTLY pretix_addidx_event_name
|
||||
ON pretixbase_event
|
||||
USING gin (upper("name") gin_trgm_ops);
|
||||
CREATE INDEX CONCURRENTLY pretix_addidx_order_code
|
||||
ON pretixbase_order
|
||||
USING gin (upper("code") gin_trgm_ops);
|
||||
CREATE INDEX CONCURRENTLY pretix_addidx_voucher_code
|
||||
ON pretixbase_voucher
|
||||
USING gin (upper("code") gin_trgm_ops);
|
||||
CREATE INDEX CONCURRENTLY pretix_addidx_invoice_nu1
|
||||
ON "pretixbase_invoice" (UPPER("invoice_no"));
|
||||
CREATE INDEX CONCURRENTLY pretix_addidx_invoice_nu2
|
||||
ON "pretixbase_invoice" (UPPER("full_invoice_no"));
|
||||
CREATE INDEX CONCURRENTLY pretix_addidx_organizer_name
|
||||
ON pretixbase_organizer
|
||||
USING gin (upper("name") gin_trgm_ops);
|
||||
CREATE INDEX CONCURRENTLY pretix_addidx_organizer_slug
|
||||
ON pretixbase_organizer
|
||||
USING gin (upper("slug") gin_trgm_ops);
|
||||
CREATE INDEX CONCURRENTLY pretix_addidx_order_email
|
||||
ON pretixbase_order
|
||||
USING gin (upper("email") gin_trgm_ops);
|
||||
CREATE INDEX CONCURRENTLY pretix_addidx_order_comment
|
||||
ON pretixbase_order
|
||||
USING gin (upper("comment") gin_trgm_ops);
|
||||
CREATE INDEX CONCURRENTLY pretix_addidx_order_event_date_id
|
||||
ON public.pretixbase_order (event_id, datetime, id);
|
||||
CREATE INDEX CONCURRENTLY pretix_addidx_orderpos_name
|
||||
ON pretixbase_orderposition
|
||||
USING gin (upper("attendee_name_cached") gin_trgm_ops);
|
||||
CREATE INDEX CONCURRENTLY pretix_addidx_orderpos_secret
|
||||
ON pretixbase_orderposition
|
||||
USING gin (upper("secret") gin_trgm_ops);
|
||||
CREATE INDEX CONCURRENTLY pretix_addidx_orderpos_email
|
||||
ON pretixbase_orderposition
|
||||
USING gin (upper("attendee_email") gin_trgm_ops);
|
||||
CREATE INDEX CONCURRENTLY pretix_addidx_ia_name
|
||||
ON pretixbase_invoiceaddress
|
||||
USING gin (upper("name_cached") gin_trgm_ops);
|
||||
CREATE INDEX CONCURRENTLY pretix_addidx_ia_company
|
||||
ON pretixbase_invoiceaddress
|
||||
USING gin (upper("company") gin_trgm_ops);
|
||||
CREATE INDEX CONCURRENTLY pretix_addidx_orderpos_email_upper
|
||||
ON public.pretixbase_orderposition (upper((attendee_email)::text));
|
||||
CREATE INDEX CONCURRENTLY pretix_addidx_voucher_code_upper
|
||||
ON public.pretixbase_voucher (upper((code)::text));
|
||||
CREATE INDEX CONCURRENTLY pretix_addidx_logentry_event_date_id
|
||||
ON public.pretixbase_logentry (event_id, datetime, id);
|
||||
CREATE INDEX CONCURRENTLY pretix_addidx_logentry_event_cid_date_id
|
||||
ON public.pretixbase_logentry (event_id, content_type_id, datetime, id);
|
||||
|
||||
|
||||
Also, if you use our ``pretix-shipping`` plugin::
|
||||
|
||||
CREATE INDEX CONCURRENTLY pretix_addidx_sa_name
|
||||
ON pretix_shipping_shippingaddress
|
||||
USING gin (upper("name") gin_trgm_ops);
|
||||
CREATE INDEX CONCURRENTLY pretix_addidx_sa_company
|
||||
ON pretix_shipping_shippingaddress
|
||||
USING gin (upper("company") gin_trgm_ops);
|
||||
|
||||
@@ -1,18 +0,0 @@
|
||||
.. highlight:: none
|
||||
|
||||
.. _`community`:
|
||||
|
||||
Community install guides
|
||||
========================
|
||||
|
||||
.. warning:: The guides are maintained by the community and not by the pretix core team. If you encounter any issues with the guides, please report them to the maintainers of the guides. The pretix core team can not provide support for installs using these guides.
|
||||
|
||||
Kubernetes
|
||||
----------
|
||||
|
||||
- Helm Chart by techwolf12 - A Helm chart for deploying pretix on Kubernetes. The chart documentation is available on `ArtifactHub <https://artifacthub.io/packages/helm/techwolf12/pretix>`_ and the source code is available on `GitHub <https://github.com/Techwolf12/charts/tree/main/pretix-helm>`_.
|
||||
|
||||
Docker
|
||||
------
|
||||
|
||||
- `docker compose setup <https://github.com/ZPascal/pretix-docker-compose>`_ by ZPascal
|
||||
@@ -1,37 +0,0 @@
|
||||
.. highlight:: none
|
||||
|
||||
Installing a development version
|
||||
================================
|
||||
|
||||
If you want to use a feature of pretix that is not yet contained in the last monthly release, you can also
|
||||
install a development version with pretix.
|
||||
|
||||
.. warning:: When in production, we strongly recommend only installing released versions. Development versions might
|
||||
be broken, incompatible to plugins, or in rare cases incompatible to upgrade later on.
|
||||
|
||||
|
||||
Manual installation
|
||||
-------------------
|
||||
|
||||
You can use ``pip`` to update pretix directly to the development branch. Then, upgrade as usual::
|
||||
|
||||
$ source /var/pretix/venv/bin/activate
|
||||
(venv)$ pip3 install -U "git+https://github.com/pretix/pretix.git#egg=pretix"
|
||||
(venv)$ python -m pretix migrate
|
||||
(venv)$ python -m pretix rebuild
|
||||
(venv)$ python -m pretix updateassets
|
||||
# systemctl restart pretix-web pretix-worker
|
||||
|
||||
Docker installation
|
||||
-------------------
|
||||
|
||||
To use the latest development version with Docker, first pull it from Docker Hub::
|
||||
|
||||
$ docker pull pretix/standalone:latest
|
||||
|
||||
|
||||
Then change your ``/etc/systemd/system/pretix.service`` file to use the ``:latest`` tag instead of ``:stable`` as well
|
||||
and upgrade as usual::
|
||||
|
||||
$ systemctl restart pretix.service
|
||||
$ docker exec -it pretix.service pretix upgrade
|
||||
@@ -1,333 +0,0 @@
|
||||
.. highlight:: none
|
||||
|
||||
.. _`dockersmallscale`:
|
||||
|
||||
Small-scale deployment with Docker
|
||||
==================================
|
||||
|
||||
This guide describes the installation of a small-scale installation of pretix using docker. By small-scale, we mean
|
||||
that everything is being run on one host and you don't expect thousands of participants trying to get a ticket within
|
||||
a few minutes. In this setup, as many parts of pretix as possible are hidden away in one single docker container.
|
||||
This has some trade-offs in terms of performance and isolation but allows a rather easy installation.
|
||||
|
||||
.. warning:: Even though we try to make it straightforward to run pretix, it still requires some Linux experience to
|
||||
get it right. If you're not feeling comfortable managing a Linux server, check out our hosting and service
|
||||
offers at `pretix.eu`_.
|
||||
|
||||
We tested this guide on the Linux distribution **Debian 11.0** but it should work very similar on other
|
||||
modern distributions, especially on all systemd-based ones.
|
||||
|
||||
Requirements
|
||||
------------
|
||||
|
||||
Please set up the following systems beforehand, we'll not explain them here (but see these links for external
|
||||
installation guides):
|
||||
|
||||
* `Docker`_
|
||||
* A SMTP server to send out mails, e.g. `Postfix`_ on your machine or some third-party server you have credentials for
|
||||
* A HTTP reverse proxy, e.g. `nginx`_ or Apache to allow HTTPS connections
|
||||
* A `PostgreSQL`_ 12+ database server
|
||||
* A `redis`_ server
|
||||
|
||||
We also recommend that you use a firewall, although this is not a pretix-specific recommendation. If you're new to
|
||||
Linux and firewalls, we recommend that you start with `ufw`_.
|
||||
|
||||
.. note:: Please, do not run pretix without HTTPS encryption. You'll handle user data and thanks to `Let's Encrypt`_
|
||||
SSL certificates can be obtained for free these days. We also *do not* provide support for HTTP-only
|
||||
installations except for evaluation purposes.
|
||||
|
||||
.. warning:: By default, using `ufw` in conjunction will not have any effect. Please make sure to either bind the exposed
|
||||
ports of your docker container explicitly to 127.0.0.1 or configure docker to respect any set up firewall
|
||||
rules.
|
||||
|
||||
On this guide
|
||||
-------------
|
||||
|
||||
All code lines prepended with a ``#`` symbol are commands that you need to execute on your server as ``root`` user;
|
||||
all lines prepended with a ``$`` symbol can also be run by an unprivileged user.
|
||||
|
||||
Data files
|
||||
----------
|
||||
|
||||
First of all, you need to create a directory on your server that pretix can use to store data files and make that
|
||||
directory writable to the user that runs pretix inside the docker container::
|
||||
|
||||
# mkdir /var/pretix-data
|
||||
# chown -R 15371:15371 /var/pretix-data
|
||||
|
||||
Database
|
||||
--------
|
||||
|
||||
Next, we need a database and a database user. We can create these with any kind of database managing tool or directly on
|
||||
our database's shell. Please make sure that UTF8 is used as encoding for the best compatibility. You can check this with
|
||||
the following command::
|
||||
|
||||
# sudo -u postgres psql -c 'SHOW SERVER_ENCODING'
|
||||
|
||||
For PostgreSQL database creation, we would do::
|
||||
|
||||
# sudo -u postgres createuser -P pretix
|
||||
# sudo -u postgres createdb -O pretix pretix
|
||||
|
||||
Make sure that your database listens on the network. If PostgreSQL on the same same host as docker, but not inside a docker container, we recommend that you just listen on the Docker interface by changing the following line in ``/etc/postgresql/<version>/main/postgresql.conf``::
|
||||
|
||||
listen_addresses = 'localhost,172.17.0.1'
|
||||
|
||||
You also need to add a new line to ``/etc/postgresql/<version>/main/pg_hba.conf`` to allow network connections to this user and database::
|
||||
|
||||
host pretix pretix 172.17.0.1/16 md5
|
||||
|
||||
Restart PostgreSQL after you changed these files::
|
||||
|
||||
# systemctl restart postgresql
|
||||
|
||||
If you have a firewall running, you should also make sure that port 5432 is reachable from the ``172.17.0.1/16`` subnet.
|
||||
|
||||
Redis
|
||||
-----
|
||||
|
||||
For caching and messaging in small-scale setups, pretix recommends using redis. In this small-scale setup we assume a
|
||||
redis instance to be running on the same host. To avoid the hassle with network configurations and firewalls, we
|
||||
recommend connecting to redis via a unix socket. To enable redis on unix sockets, add the following to your
|
||||
``/etc/redis/redis.conf``::
|
||||
|
||||
unixsocket /var/run/redis/redis.sock
|
||||
unixsocketperm 777
|
||||
|
||||
Now restart redis-server::
|
||||
|
||||
# systemctl restart redis-server
|
||||
|
||||
In this setup, systemd will delete ``/var/run/redis`` on every redis restart, which will cause issues with pretix. To
|
||||
prevent this, you can execute::
|
||||
|
||||
# systemctl edit redis-server
|
||||
|
||||
And insert the following::
|
||||
|
||||
[Service]
|
||||
# Keep the directory around so that pretix.service in docker does not need to be
|
||||
# restarted when redis is restarted.
|
||||
RuntimeDirectoryPreserve=yes
|
||||
|
||||
.. warning:: Setting the socket permissions to 777 is a possible security problem. If you have untrusted users on your
|
||||
system or have high security requirements, please don't do this and let redis listen to a TCP socket
|
||||
instead. We recommend the socket approach because the TCP socket in combination with docker's networking
|
||||
can easily become an even worse security hole when configured slightly wrong. Read more about security
|
||||
on the `redis website`_.
|
||||
|
||||
Another possible solution is to run `redis in docker`_ and link the containers using docker's networking
|
||||
features.
|
||||
|
||||
Config file
|
||||
-----------
|
||||
|
||||
We now create a config directory and config file for pretix::
|
||||
|
||||
# mkdir /etc/pretix
|
||||
# touch /etc/pretix/pretix.cfg
|
||||
# chown -R 15371:15371 /etc/pretix/
|
||||
# chmod 0700 /etc/pretix/pretix.cfg
|
||||
|
||||
Fill the configuration file ``/etc/pretix/pretix.cfg`` with the following content (adjusted to your environment)::
|
||||
|
||||
[pretix]
|
||||
instance_name=My pretix installation
|
||||
url=https://pretix.mydomain.com
|
||||
currency=EUR
|
||||
; DO NOT change the following value, it has to be set to the location of the
|
||||
; directory *inside* the docker container
|
||||
datadir=/data
|
||||
trust_x_forwarded_for=on
|
||||
trust_x_forwarded_proto=on
|
||||
|
||||
[database]
|
||||
backend=postgresql
|
||||
name=pretix
|
||||
user=pretix
|
||||
; Replace with the password you chose above
|
||||
password=*********
|
||||
; In most docker setups, 172.17.0.1 is the address of the docker host. Adjust
|
||||
; this to wherever your database is running, e.g. the name of a linked container.
|
||||
host=172.17.0.1
|
||||
|
||||
[mail]
|
||||
; See config file documentation for more options
|
||||
from=tickets@yourdomain.com
|
||||
; This is the default IP address of your docker host in docker's virtual
|
||||
; network. Make sure postfix listens on this address.
|
||||
host=172.17.0.1
|
||||
|
||||
[redis]
|
||||
location=unix:///var/run/redis/redis.sock?db=0
|
||||
; Remove the following line if you are unsure about your redis' security
|
||||
; to reduce impact if redis gets compromised.
|
||||
sessions=true
|
||||
|
||||
[celery]
|
||||
backend=redis+socket:///var/run/redis/redis.sock?virtual_host=1
|
||||
broker=redis+socket:///var/run/redis/redis.sock?virtual_host=2
|
||||
|
||||
See :ref:`email configuration <mail-settings>` to learn more about configuring mail features.
|
||||
|
||||
Docker image and service
|
||||
------------------------
|
||||
|
||||
First of all, download the latest stable pretix image by running::
|
||||
|
||||
$ docker pull pretix/standalone:stable
|
||||
|
||||
We recommend starting the docker container using systemd to make sure it runs correctly after a reboot. Create a file
|
||||
named ``/etc/systemd/system/pretix.service`` with the following content::
|
||||
|
||||
[Unit]
|
||||
Description=pretix
|
||||
After=docker.service
|
||||
Requires=docker.service
|
||||
|
||||
[Service]
|
||||
TimeoutStartSec=0
|
||||
ExecStartPre=-/usr/bin/docker kill %n
|
||||
ExecStartPre=-/usr/bin/docker rm %n
|
||||
ExecStart=/usr/bin/docker run --name %n -p 127.0.0.1:8345:80 \
|
||||
-v /var/pretix-data:/data \
|
||||
-v /etc/pretix:/etc/pretix \
|
||||
-v /var/run/redis:/var/run/redis \
|
||||
--sysctl net.core.somaxconn=4096 \
|
||||
pretix/standalone:stable all
|
||||
ExecStop=/usr/bin/docker stop %n
|
||||
|
||||
[Install]
|
||||
WantedBy=multi-user.target
|
||||
|
||||
You can now run the following commands
|
||||
to enable and start the service::
|
||||
|
||||
# systemctl daemon-reload
|
||||
# systemctl enable pretix
|
||||
# systemctl start pretix
|
||||
|
||||
Cronjob
|
||||
-------
|
||||
|
||||
You need to set up a cronjob that runs the management command ``runperiodic``. The exact interval is not important
|
||||
but should be something between every minute and every hour. You could for example configure cron like this::
|
||||
|
||||
15,45 * * * * /usr/bin/docker exec pretix.service pretix cron
|
||||
|
||||
The cronjob may run as any user that can use the docker daemon.
|
||||
|
||||
SSL
|
||||
---
|
||||
|
||||
The following snippet is an example on how to configure a nginx proxy for pretix::
|
||||
|
||||
server {
|
||||
listen 80 default_server;
|
||||
listen [::]:80 ipv6only=on default_server;
|
||||
server_name pretix.mydomain.com;
|
||||
location / {
|
||||
return 301 https://$host$request_uri;
|
||||
}
|
||||
}
|
||||
server {
|
||||
listen 443 ssl default_server;
|
||||
listen [::]:443 ipv6only=on ssl default_server;
|
||||
server_name pretix.mydomain.com;
|
||||
|
||||
ssl_certificate /path/to/cert.chain.pem;
|
||||
ssl_certificate_key /path/to/key.pem;
|
||||
|
||||
location / {
|
||||
proxy_pass http://localhost:8345;
|
||||
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
|
||||
proxy_set_header X-Forwarded-Proto https;
|
||||
proxy_set_header Host $http_host;
|
||||
}
|
||||
}
|
||||
|
||||
|
||||
We recommend reading about setting `strong encryption settings`_ for your web server.
|
||||
|
||||
Next steps
|
||||
----------
|
||||
|
||||
Yay, you are done! You should now be able to reach pretix at https://pretix.yourdomain.com/control/ and log in as
|
||||
*admin@localhost* with a password of *admin*. Don't forget to change that password! Create an organizer first, then
|
||||
create an event and start selling tickets!
|
||||
|
||||
You should probably read :ref:`maintainance` next.
|
||||
|
||||
.. _`docker_updates`:
|
||||
|
||||
Updates
|
||||
-------
|
||||
|
||||
.. warning:: While we try hard not to break things, **please perform a backup before every upgrade**.
|
||||
|
||||
Updates are fairly simple, but require at least a short downtime::
|
||||
|
||||
# docker pull pretix/standalone:stable
|
||||
# systemctl restart pretix.service
|
||||
# docker exec -it pretix.service pretix upgrade
|
||||
|
||||
Restarting the service can take a few seconds, especially if the update requires changes to the database.
|
||||
Replace ``stable`` above with a specific version number like ``1.0`` or with ``latest`` for the development
|
||||
version, if you want to.
|
||||
|
||||
Make sure to also read :ref:`update_notes` and the release notes of the version you are updating to. Pay special
|
||||
attention to the "Runtime and server environment" section of all release notes between your current and new version.
|
||||
|
||||
.. _`docker_plugininstall`:
|
||||
|
||||
Install a plugin
|
||||
----------------
|
||||
|
||||
To install a plugin, you need to build your own docker image. To do so, create a new directory and place a file
|
||||
named ``Dockerfile`` in it. The Dockerfile could look like this (replace ``pretix-passbook`` with the plugins of your
|
||||
choice)::
|
||||
|
||||
FROM pretix/standalone:stable
|
||||
USER root
|
||||
RUN pip3 install pretix-passbook
|
||||
USER pretixuser
|
||||
RUN cd /pretix/src && make production
|
||||
|
||||
Then, go to that directory and build the image::
|
||||
|
||||
$ docker build . -t mypretix
|
||||
|
||||
You can now use that image ``mypretix`` instead of ``pretix/standalone`` in your service file (see above). Be sure
|
||||
to re-build your custom image after you pulled ``pretix/standalone`` if you want to perform an update.
|
||||
|
||||
Scaling up
|
||||
----------
|
||||
|
||||
If you need to scale to multiple machines, please first read our :ref:`scaling guide <scaling>`.
|
||||
|
||||
If you run the official docker container on multiple machines, it is recommended to set the environment
|
||||
variable ``AUTOMIGRATE=skip`` on all containers and run ``docker exec -it pretix.service pretix migrate``
|
||||
on one machine after each upgrade manually, otherwise multiple containers might try to upgrade the
|
||||
database schema at the same time.
|
||||
|
||||
To run only the ``pretix-web`` component of pretix as well as a nginx server serving static files, you
|
||||
can invoke the container with ``docker run … pretix/standalone:stable web`` (instead of ``all``). You
|
||||
can adjust the number of ``gunicorn`` processes with the ``NUM_WORKERS`` environment variable (defaults to
|
||||
two times the number of CPUs detected).
|
||||
|
||||
To run only ``pretix-worker``, you can run ``docker run … pretix/standalone:stable taskworker``. You can
|
||||
also pass arguments to limit the worker to specific queues or to change the number of concurrent task
|
||||
workers, e.g. ``docker run … taskworker -Q notifications --concurrency 32``.
|
||||
|
||||
|
||||
.. _Docker: https://docs.docker.com/engine/installation/linux/debian/
|
||||
.. _Postfix: https://www.digitalocean.com/community/tutorials/how-to-install-and-configure-postfix-as-a-send-only-smtp-server-on-ubuntu-22-04
|
||||
.. _nginx: https://botleg.com/stories/https-with-lets-encrypt-and-nginx/
|
||||
.. _Let's Encrypt: https://letsencrypt.org/
|
||||
.. _pretix.eu: https://pretix.eu/
|
||||
.. _PostgreSQL: https://www.digitalocean.com/community/tutorials/how-to-install-and-use-postgresql-on-ubuntu-22-04
|
||||
.. _redis: https://blog.programster.org/debian-8-install-redis-server/
|
||||
.. _ufw: https://en.wikipedia.org/wiki/Uncomplicated_Firewall
|
||||
.. _redis website: https://redis.io/topics/security
|
||||
.. _redis in docker: https://hub.docker.com/r/_/redis/
|
||||
.. _strong encryption settings: https://mozilla.github.io/server-side-tls/ssl-config-generator/
|
||||
@@ -1,84 +0,0 @@
|
||||
.. highlight:: none
|
||||
|
||||
Installing pretix Enterprise plugins
|
||||
====================================
|
||||
|
||||
If you want to use a feature of pretix that is part of our commercial offering pretix Enterprise, you need to follow
|
||||
some extra steps. Installation works similar to normal pretix plugins, but involves a few extra steps.
|
||||
|
||||
Buying the license
|
||||
------------------
|
||||
|
||||
To obtain a license, please get in touch at sales@pretix.eu. Please let us know how many tickets you roughly intend
|
||||
to sell per year and how many servers you want to use the plugin on. We recommend having a look at our `price list`_
|
||||
first.
|
||||
|
||||
|
||||
Manual installation
|
||||
-------------------
|
||||
|
||||
First, generate an SSH key for the system user that you install pretix as. In our tutorial, that would be the user
|
||||
``pretix``. Choose an empty passphrase::
|
||||
|
||||
# su pretix
|
||||
$ ssh-keygen
|
||||
Generating public/private rsa key pair.
|
||||
Enter file in which to save the key (/var/pretix/.ssh/id_rsa):
|
||||
Enter passphrase (empty for no passphrase):
|
||||
Enter same passphrase again:
|
||||
Your identification has been saved in /var/pretix/.ssh/id_rsa.
|
||||
Your public key has been saved in /var/pretix/.ssh/id_rsa.pub.
|
||||
|
||||
Next, send the content of the *public* key to your sales representative at pretix::
|
||||
|
||||
$ cat /var/pretix/.ssh/id_rsa.pub
|
||||
ssh-rsa AAAAB3N...744HZawHlD pretix@foo
|
||||
|
||||
After we configured your key in our system, you can install the plugin directly using ``pip`` from the URL we told
|
||||
you, for example::
|
||||
|
||||
$ source /var/pretix/venv/bin/activate
|
||||
(venv)$ pip3 install -U "git+ssh://git@code.rami.io:10022/pretix/pretix-slack.git@stable#egg=pretix-slack"
|
||||
(venv)$ python -m pretix migrate
|
||||
(venv)$ python -m pretix rebuild
|
||||
# systemctl restart pretix-web pretix-worker
|
||||
|
||||
Docker installation
|
||||
-------------------
|
||||
|
||||
To install a plugin, you need to build your own docker image. To do so, create a new directory to work in. As a first
|
||||
step, generate a new SSH key in that directory to use for authentication with us::
|
||||
|
||||
$ cd /home/me/mypretixdocker
|
||||
$ ssh-keygen -N "" -f id_pretix_enterprise
|
||||
|
||||
Next, send the content of the *public* key to your sales representative at pretix::
|
||||
|
||||
$ cat id_pretix_enterprise.pub
|
||||
ssh-rsa AAAAB3N...744HZawHlD pretix@foo
|
||||
|
||||
After we configured your key in our system, you can add a ``Dockerfile`` in your directory that includes the newly
|
||||
generated key and installs the plugin from the URL we told you::
|
||||
|
||||
FROM pretix/standalone:stable
|
||||
USER root
|
||||
COPY id_pretix_enterprise /root/.ssh/id_rsa
|
||||
COPY id_pretix_enterprise.pub /root/.ssh/id_rsa.pub
|
||||
RUN chmod -R 0600 /root/.ssh && \
|
||||
mkdir -p /etc/ssh && \
|
||||
ssh-keyscan -t rsa -p 10022 code.rami.io >> /root/.ssh/known_hosts && \
|
||||
echo StrictHostKeyChecking=no >> /root/.ssh/config && \
|
||||
DJANGO_SETTINGS_MODULE= pip3 install -U "git+ssh://git@code.rami.io:10022/pretix/pretix-slack.git@stable#egg=pretix-slack" && \
|
||||
cd /pretix/src && \
|
||||
sudo -u pretixuser make production
|
||||
USER pretixuser
|
||||
|
||||
Then, build the image for docker::
|
||||
|
||||
$ docker build -t mypretix
|
||||
|
||||
You can now use that image ``mypretix`` instead of ``pretix/standalone:stable`` in your ``/etc/systemd/system/pretix.service``
|
||||
service file. Be sure to re-build your custom image after you pulled ``pretix/standalone`` if you want to perform an
|
||||
update to a new version of pretix.
|
||||
|
||||
.. _price list: https://pretix.eu/about/en/pricing
|
||||
@@ -1,39 +0,0 @@
|
||||
.. highlight:: ini
|
||||
|
||||
.. spelling:word-list:: SQL
|
||||
|
||||
General remarks
|
||||
===============
|
||||
|
||||
Requirements
|
||||
------------
|
||||
To use pretix, you will need the following things:
|
||||
|
||||
* **pretix** and the python packages it depends on
|
||||
|
||||
* An **WSGI application server** (we recommend gunicorn)
|
||||
|
||||
* A periodic task runner, e.g. ``cron``
|
||||
|
||||
* **A database**. This needs to be a SQL-based that is supported by Django. We highly recommend to either
|
||||
go for **PostgreSQL**. If you do not provide one, pretix will run on SQLite, which is useful
|
||||
for evaluation and development purposes.
|
||||
|
||||
.. warning:: Do not ever use SQLite in production. It will break.
|
||||
|
||||
* A **reverse proxy**. pretix needs to deliver some static content to your users (e.g. CSS, images, ...). While pretix
|
||||
is capable of doing this, having this handled by a proper web server like **nginx** or **Apache** will be much
|
||||
faster. Also, you need a proxying web server in front to provide SSL encryption.
|
||||
|
||||
.. warning:: Do not ever run without SSL in production. Your users deserve encrypted connections and thanks to
|
||||
`Let's Encrypt`_ SSL certificates can be obtained for free these days.
|
||||
|
||||
* A **redis** server. This will be used for caching, session storage and task queuing.
|
||||
|
||||
.. warning:: pretix can run without redis, however this is only intended for development and should never be
|
||||
used in production.
|
||||
|
||||
* Optionally: RabbitMQ or memcached. Both of them might provide speedups, but if they are not present,
|
||||
redis will take over their job.
|
||||
|
||||
.. _Let's Encrypt: https://letsencrypt.org/
|
||||
@@ -1,17 +0,0 @@
|
||||
.. _`installation`:
|
||||
|
||||
Installation guide
|
||||
==================
|
||||
|
||||
We provide you with multiple installation guides for multiple types of setups so you can choose the one appropriate
|
||||
for your needs.
|
||||
|
||||
.. toctree::
|
||||
:maxdepth: 1
|
||||
|
||||
general
|
||||
docker_smallscale
|
||||
manual_smallscale
|
||||
dev_version
|
||||
enterprise
|
||||
community
|
||||
@@ -1,346 +0,0 @@
|
||||
.. highlight:: none
|
||||
|
||||
Small-scale manual deployment
|
||||
=============================
|
||||
|
||||
This guide describes the installation of a small-scale installation of pretix from source. By small-scale, we mean
|
||||
that everything is being run on one host and you don't expect thousands of participants trying to get a ticket within
|
||||
a few minutes. In this setup, you will have to perform a number of manual steps. If you prefer using a container
|
||||
solution with many things readily set-up, look at :ref:`dockersmallscale`.
|
||||
|
||||
.. warning:: Even though we try to make it straightforward to run pretix, it still requires some Linux experience to
|
||||
get it right. If you're not feeling comfortable managing a Linux server, check out our hosting and service
|
||||
offers at `pretix.eu`_.
|
||||
|
||||
We tested this guide on the Linux distribution **Debian 12** but it should work very similar on other
|
||||
modern distributions, especially on all systemd-based ones.
|
||||
|
||||
Requirements
|
||||
------------
|
||||
|
||||
Please set up the following systems beforehand, we'll not explain them here in detail (but see these links for external
|
||||
installation guides):
|
||||
|
||||
* A python 3.9+ installation
|
||||
* A SMTP server to send out mails, e.g. `Postfix`_ on your machine or some third-party server you have credentials for
|
||||
* A HTTP reverse proxy, e.g. `nginx`_ or Apache to allow HTTPS connections
|
||||
* A `PostgreSQL`_ 12+ database server
|
||||
* A `redis`_ server
|
||||
* A `nodejs`_ installation
|
||||
|
||||
We also recommend that you use a firewall, although this is not a pretix-specific recommendation. If you're new to
|
||||
Linux and firewalls, we recommend that you start with `ufw`_.
|
||||
|
||||
.. note:: Please, do not run pretix without HTTPS encryption. You'll handle user data and thanks to `Let's Encrypt`_
|
||||
SSL certificates can be obtained for free these days. We also *do not* provide support for HTTP-only
|
||||
installations except for evaluation purposes.
|
||||
|
||||
Unix user
|
||||
---------
|
||||
|
||||
As we do not want to run pretix as root, we first create a new unprivileged user::
|
||||
|
||||
# adduser pretix --disabled-password --home /var/pretix
|
||||
|
||||
In this guide, all code lines prepended with a ``#`` symbol are commands that you need to execute on your server as
|
||||
``root`` user (e.g. using ``sudo``); all lines prepended with a ``$`` symbol should be run by the unprivileged user.
|
||||
|
||||
Database
|
||||
--------
|
||||
|
||||
Having the database server installed, we still need a database and a database user. We can create these with any kind
|
||||
of database managing tool or directly on our database's shell. Please make sure that UTF8 is used as encoding for the
|
||||
best compatibility. You can check this with the following command::
|
||||
|
||||
# sudo -u postgres psql -c 'SHOW SERVER_ENCODING'
|
||||
|
||||
For PostgreSQL database creation, we would do::
|
||||
|
||||
# sudo -u postgres createuser pretix
|
||||
# sudo -u postgres createdb -O pretix pretix
|
||||
|
||||
Package dependencies
|
||||
--------------------
|
||||
|
||||
To build and run pretix, you will need the following debian packages::
|
||||
|
||||
# apt-get install git build-essential python3-dev python3-venv python3 python3-pip \
|
||||
libxml2-dev libxslt1-dev libffi-dev zlib1g-dev libssl-dev \
|
||||
gettext libpq-dev libjpeg-dev libopenjp2-7-dev
|
||||
|
||||
Config file
|
||||
-----------
|
||||
|
||||
We now create a config directory and config file for pretix::
|
||||
|
||||
# mkdir /etc/pretix
|
||||
# touch /etc/pretix/pretix.cfg
|
||||
# chown -R pretix:pretix /etc/pretix/
|
||||
# chmod 0600 /etc/pretix/pretix.cfg
|
||||
|
||||
Fill the configuration file ``/etc/pretix/pretix.cfg`` with the following content (adjusted to your environment)::
|
||||
|
||||
[pretix]
|
||||
instance_name=My pretix installation
|
||||
url=https://pretix.mydomain.com
|
||||
currency=EUR
|
||||
datadir=/var/pretix/data
|
||||
trust_x_forwarded_for=on
|
||||
trust_x_forwarded_proto=on
|
||||
|
||||
[database]
|
||||
backend=postgresql
|
||||
name=pretix
|
||||
user=pretix
|
||||
; For PostgreSQL on the same host, we don't need a password because we can use
|
||||
; peer authentication if our PostgreSQL user matches our unix user.
|
||||
password=
|
||||
; For local postgres authentication, you can leave it empty
|
||||
host=
|
||||
|
||||
[mail]
|
||||
; See config file documentation for more options
|
||||
from=tickets@yourdomain.com
|
||||
host=127.0.0.1
|
||||
|
||||
[redis]
|
||||
location=redis://127.0.0.1/0
|
||||
sessions=true
|
||||
|
||||
[celery]
|
||||
backend=redis://127.0.0.1/1
|
||||
broker=redis://127.0.0.1/2
|
||||
|
||||
See :ref:`email configuration <mail-settings>` to learn more about configuring mail features.
|
||||
|
||||
Install pretix from PyPI
|
||||
------------------------
|
||||
|
||||
Now we will install pretix itself. The following steps are to be executed as the ``pretix`` user. Before we
|
||||
actually install pretix, we will create a virtual environment to isolate the python packages from your global
|
||||
python installation::
|
||||
|
||||
# sudo -u pretix -s
|
||||
$ python3 -m venv /var/pretix/venv
|
||||
$ source /var/pretix/venv/bin/activate
|
||||
(venv)$ pip3 install -U pip setuptools wheel
|
||||
|
||||
We now install pretix, its direct dependencies and gunicorn::
|
||||
|
||||
(venv)$ pip3 install pretix gunicorn
|
||||
|
||||
Note that you need Python 3.9 or newer. You can find out your Python version using ``python -V``.
|
||||
|
||||
We also need to create a data directory and allow your webserver to traverse to the root directory::
|
||||
|
||||
(venv)$ mkdir -p /var/pretix/data/media
|
||||
(venv)$ chmod +x /var/pretix
|
||||
|
||||
Finally, we compile static files and translation data and create the database structure::
|
||||
|
||||
(venv)$ python -m pretix migrate
|
||||
(venv)$ python -m pretix rebuild
|
||||
|
||||
|
||||
Start pretix as a service
|
||||
-------------------------
|
||||
|
||||
We recommend starting pretix using systemd to make sure it runs correctly after a reboot. Create a file
|
||||
named ``/etc/systemd/system/pretix-web.service`` with the following content::
|
||||
|
||||
[Unit]
|
||||
Description=pretix web service
|
||||
After=network.target
|
||||
|
||||
[Service]
|
||||
User=pretix
|
||||
Group=pretix
|
||||
Environment="VIRTUAL_ENV=/var/pretix/venv"
|
||||
Environment="PATH=/var/pretix/venv/bin:/usr/local/bin:/usr/bin:/bin"
|
||||
ExecStart=/var/pretix/venv/bin/gunicorn pretix.wsgi \
|
||||
--name pretix --workers 5 \
|
||||
--max-requests 1200 --max-requests-jitter 50 \
|
||||
--log-level=info --bind=127.0.0.1:8345
|
||||
WorkingDirectory=/var/pretix
|
||||
Restart=on-failure
|
||||
|
||||
[Install]
|
||||
WantedBy=multi-user.target
|
||||
|
||||
For background tasks we need a second service ``/etc/systemd/system/pretix-worker.service`` with the following content::
|
||||
|
||||
[Unit]
|
||||
Description=pretix background worker
|
||||
After=network.target
|
||||
|
||||
[Service]
|
||||
User=pretix
|
||||
Group=pretix
|
||||
Environment="VIRTUAL_ENV=/var/pretix/venv"
|
||||
Environment="PATH=/var/pretix/venv/bin:/usr/local/bin:/usr/bin:/bin"
|
||||
ExecStart=/var/pretix/venv/bin/celery -A pretix.celery_app worker -l info
|
||||
WorkingDirectory=/var/pretix
|
||||
Restart=on-failure
|
||||
|
||||
[Install]
|
||||
WantedBy=multi-user.target
|
||||
|
||||
You can now run the following commands to enable and start the services::
|
||||
|
||||
# systemctl daemon-reload
|
||||
# systemctl enable pretix-web pretix-worker
|
||||
# systemctl start pretix-web pretix-worker
|
||||
|
||||
|
||||
Cronjob
|
||||
-------
|
||||
|
||||
You need to set up a cronjob that runs the management command ``runperiodic``. The exact interval is not important
|
||||
but should be something between every minute and every hour. You could for example configure cron like this::
|
||||
|
||||
15,45 * * * * export PATH=/var/pretix/venv/bin:$PATH && cd /var/pretix && python -m pretix runperiodic
|
||||
|
||||
The cronjob should run as the ``pretix`` user (``crontab -e -u pretix``).
|
||||
|
||||
SSL
|
||||
---
|
||||
|
||||
The following snippet is an example on how to configure a nginx proxy for pretix::
|
||||
|
||||
server {
|
||||
listen 80 default_server;
|
||||
listen [::]:80 ipv6only=on default_server;
|
||||
server_name pretix.mydomain.com;
|
||||
location / {
|
||||
return 301 https://$host$request_uri;
|
||||
}
|
||||
}
|
||||
server {
|
||||
listen 443 ssl default_server;
|
||||
listen [::]:443 ipv6only=on ssl default_server;
|
||||
server_name pretix.mydomain.com;
|
||||
|
||||
ssl_certificate /path/to/cert.chain.pem;
|
||||
ssl_certificate_key /path/to/key.pem;
|
||||
|
||||
add_header Referrer-Policy same-origin;
|
||||
add_header X-Content-Type-Options nosniff;
|
||||
|
||||
location / {
|
||||
proxy_pass http://localhost:8345;
|
||||
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
|
||||
proxy_set_header X-Forwarded-Proto https;
|
||||
proxy_set_header Host $http_host;
|
||||
}
|
||||
|
||||
location /media/ {
|
||||
alias /var/pretix/data/media/;
|
||||
expires 7d;
|
||||
access_log off;
|
||||
}
|
||||
|
||||
location ^~ /media/cachedfiles {
|
||||
deny all;
|
||||
return 404;
|
||||
}
|
||||
location ^~ /media/invoices {
|
||||
deny all;
|
||||
return 404;
|
||||
}
|
||||
|
||||
location /static/staticfiles.json {
|
||||
deny all;
|
||||
return 404;
|
||||
}
|
||||
location /static/CACHE/manifest.json {
|
||||
deny all;
|
||||
return 404;
|
||||
}
|
||||
location /static/ {
|
||||
alias /var/pretix/venv/lib/python3.11/site-packages/pretix/static.dist/;
|
||||
access_log off;
|
||||
expires 365d;
|
||||
add_header Cache-Control "public";
|
||||
}
|
||||
}
|
||||
|
||||
.. note:: Remember to replace the ``python3.11`` in the ``/static/`` path in the config
|
||||
above with your python version.
|
||||
|
||||
We recommend reading about setting `strong encryption settings`_ for your web server.
|
||||
|
||||
Next steps
|
||||
----------
|
||||
|
||||
Yay, you are done! You should now be able to reach pretix at https://pretix.yourdomain.com/control/ and log in as
|
||||
*admin@localhost* with a password of *admin*. Don't forget to change that password! Create an organizer first, then
|
||||
create an event and start selling tickets!
|
||||
|
||||
You should probably read :ref:`maintainance` next.
|
||||
|
||||
.. _`manual_updates`:
|
||||
|
||||
Updates
|
||||
-------
|
||||
|
||||
.. warning:: While we try hard not to break things, **please perform a backup before every upgrade**.
|
||||
|
||||
To upgrade to a new pretix release, pull the latest code changes and run the following commands::
|
||||
|
||||
# sudo -u pretix -s
|
||||
$ source /var/pretix/venv/bin/activate
|
||||
(venv)$ pip3 install -U --upgrade-strategy eager pretix gunicorn
|
||||
(venv)$ python -m pretix migrate
|
||||
(venv)$ python -m pretix rebuild
|
||||
(venv)$ python -m pretix updateassets
|
||||
# systemctl restart pretix-web pretix-worker
|
||||
|
||||
Make sure to also read :ref:`update_notes` and the release notes of the version you are updating to. Pay special
|
||||
attention to the "Runtime and server environment" section of all release notes between your current and new version.
|
||||
|
||||
.. _`manual_plugininstall`:
|
||||
|
||||
Install a plugin
|
||||
----------------
|
||||
|
||||
To install a plugin, just use ``pip``! Depending on the plugin, you should probably apply database migrations and
|
||||
rebuild the static files afterwards. Replace ``pretix-passbook`` with the plugin of your choice in the following
|
||||
example::
|
||||
|
||||
$ source /var/pretix/venv/bin/activate
|
||||
(venv)$ pip3 install pretix-passbook
|
||||
(venv)$ python -m pretix migrate
|
||||
(venv)$ python -m pretix rebuild
|
||||
# systemctl restart pretix-web pretix-worker
|
||||
|
||||
System updates
|
||||
--------------
|
||||
|
||||
After system updates, such as updates to a new Ubuntu or Debian release, you might be using a new Python version.
|
||||
That's great, but requires some adjustments. First, adjust any old version paths in your nginx configuration file.
|
||||
Then, re-create your Python environment::
|
||||
|
||||
$ source /var/pretix/venv/bin/activate
|
||||
(venv)$ pip3 freeze > /tmp/pip-backup.txt
|
||||
$ rm -rf /var/pretix/venv
|
||||
$ python3 -m venv /var/pretix/venv
|
||||
$ source /var/pretix/venv/bin/activate
|
||||
(venv)$ pip3 install -U pip wheel setuptools
|
||||
(venv)$ pip3 install -r /tmp/pip-backup.txt
|
||||
|
||||
Then, proceed like after any plugin installation::
|
||||
|
||||
(venv)$ python -m pretix migrate
|
||||
(venv)$ python -m pretix rebuild
|
||||
(venv)$ python -m pretix updateassets
|
||||
# systemctl restart pretix-web pretix-worker
|
||||
|
||||
.. _Postfix: https://www.digitalocean.com/community/tutorials/how-to-install-and-configure-postfix-as-a-send-only-smtp-server-on-ubuntu-22-04
|
||||
.. _nginx: https://botleg.com/stories/https-with-lets-encrypt-and-nginx/
|
||||
.. _Let's Encrypt: https://letsencrypt.org/
|
||||
.. _pretix.eu: https://pretix.eu/
|
||||
.. _PostgreSQL: https://www.digitalocean.com/community/tutorials/how-to-install-and-use-postgresql-on-ubuntu-22-04
|
||||
.. _redis: https://blog.programster.org/debian-8-install-redis-server/
|
||||
.. _ufw: https://en.wikipedia.org/wiki/Uncomplicated_Firewall
|
||||
.. _strong encryption settings: https://mozilla.github.io/server-side-tls/ssl-config-generator/
|
||||
.. _nodejs: https://github.com/nodesource/distributions/blob/master/README.md#deb
|
||||
@@ -1,114 +0,0 @@
|
||||
.. highlight:: ini
|
||||
|
||||
.. _`maintainance`:
|
||||
|
||||
Backups and Monitoring
|
||||
======================
|
||||
|
||||
If you host your own pretix instance, you also need to care about the availability
|
||||
of your service and the safety of your data yourself. This page gives you some
|
||||
information that you might need to do so properly.
|
||||
|
||||
.. _`backups`:
|
||||
|
||||
Backups
|
||||
-------
|
||||
|
||||
There are essentially two things which you should create backups of:
|
||||
|
||||
Database
|
||||
Your SQL database. This is critical and you should **absolutely always create automatic
|
||||
backups of your database**. There are tons of tutorials on the internet on how to do this,
|
||||
and the exact process depends on the choice of your database. For PostgreSQL, see the
|
||||
``pg_dump`` tool. You probably want to create a cronjob that does the backups for you on a
|
||||
regular schedule.
|
||||
|
||||
Data directory
|
||||
The data directory of your pretix configuration might contain some things that you should
|
||||
back up. If you did not specify a secret in your config file, back up the ``.secret`` text
|
||||
file in the data directory. If you lose your secret, all currently active user sessions,
|
||||
password reset links and similar things will be rendered invalid. Also, you probably want
|
||||
to backup the ``media`` subdirectory of the data directory which contains all user-uploaded
|
||||
and generated files. This includes files you could in theory regenerate (ticket downloads)
|
||||
but also files that you might be legally required to keep (invoice PDFs) or files that you
|
||||
would need to re-upload (event logos, product pictures, etc.). It is up to you if you
|
||||
create regular backups of this data, but we strongly advise you to do so. You can create
|
||||
backups e.g. using ``rsync``. There is a lot of information on the internet on how to create
|
||||
backups of folders on a Linux machine.
|
||||
|
||||
There is no need to create backups of the redis database, if you use it. We only use it for
|
||||
non-critical, temporary or cached data.
|
||||
|
||||
Uptime monitoring
|
||||
-----------------
|
||||
|
||||
To monitor whether your pretix instance is running, you can issue a GET request to
|
||||
``https://pretix.mydomain.com/healthcheck/``. This endpoint tests if the connection to the
|
||||
database, to the configured cache and to redis (if used) is working correctly. If everything
|
||||
appears to work fine, an empty response with status code ``200`` is returned.
|
||||
If there is a problem, a status code in the ``5xx`` range will be returned.
|
||||
|
||||
.. _`perf-monitoring`:
|
||||
|
||||
Performance monitoring
|
||||
----------------------
|
||||
|
||||
If you want to generate detailed performance statistics of your pretix installation, there is an
|
||||
endpoint at ``https://pretix.mydomain.com/metrics`` (no slash at the end) which returns a
|
||||
number of values in the text format understood by monitoring tools like Prometheus_. This data
|
||||
is only collected and exposed if you enable it in the :ref:`metrics-settings` section of your
|
||||
pretix configuration. You can also configure basic auth credentials there to protect your
|
||||
statistics against unauthorized access. The data is temporarily collected in redis, so the
|
||||
performance impact of this feature depends on the connection to your redis database.
|
||||
|
||||
Currently, mostly response times of HTTP requests and background tasks are exposed.
|
||||
|
||||
If you want to go even further, you can set the ``profile`` option in the :ref:`django-settings`
|
||||
section to a value between 0 and 1. If you set it for example to 0.1, then 10% of your requests
|
||||
(randomly selected) will be run with cProfile_ activated. The profiling results will be saved
|
||||
to your data directory. As this might impact performance significantly and writes a lot of data
|
||||
to disk, we recommend to only enable it for a small number of requests -- and only if you are
|
||||
really interested in the results.
|
||||
|
||||
Available metrics
|
||||
^^^^^^^^^^^^^^^^^
|
||||
|
||||
The metrics available in pretix follow the standard `metric types`_ from the Prometheus world.
|
||||
Currently, the following metrics are exported:
|
||||
|
||||
pretix_view_requests_total
|
||||
Counter. Counts requests to Django views, labeled with the resolved ``url_name``, the used
|
||||
HTTP ``method`` and the ``status_code`` returned.
|
||||
|
||||
pretix_view_durations_seconds
|
||||
Histogram. Measures duration of requests to Django views, labeled with the resolved
|
||||
``url_name``, the used HTTP ``method`` and the ``status_code`` returned.
|
||||
|
||||
pretix_task_runs_total
|
||||
Counter. Counts executions of background tasks, labeled with the ``task_name`` and the
|
||||
``status``. The latter can be ``success``, ``error`` or ``expected-error``.
|
||||
|
||||
pretix_task_duration_seconds
|
||||
Histogram. Measures duration of successful background task executions, labeled with the
|
||||
``task_name``.
|
||||
|
||||
pretix_model_instances
|
||||
Gauge. Measures number of instances of a certain model within the database, labeled with
|
||||
the ``model`` name. Starting with pretix 3.11, these numbers might only be approximate for
|
||||
most tables when running on PostgreSQL to mitigate performance impact.
|
||||
|
||||
pretix_celery_tasks_queued_count
|
||||
The number of background tasks in the worker queue, labeled with ``queue``.
|
||||
|
||||
pretix_celery_tasks_queued_age_seconds
|
||||
The age of the longest-waiting in the worker queue in seconds, labeled with ``queue``.
|
||||
|
||||
pretix_logins_successful
|
||||
Counter. The number of successful backend logins.
|
||||
|
||||
pretix_logins_failed
|
||||
Counter. The number of failed backend logins, labeled with ``reason``.
|
||||
|
||||
.. _metric types: https://prometheus.io/docs/concepts/metric_types/
|
||||
.. _Prometheus: https://prometheus.io/
|
||||
.. _cProfile: https://docs.python.org/3/library/profile.html
|
||||
@@ -1,261 +0,0 @@
|
||||
.. highlight:: none
|
||||
|
||||
Migrating from MySQL/MariaDB to PostgreSQL
|
||||
==========================================
|
||||
|
||||
Our recommended database for all production installations is PostgreSQL. Support for MySQL/MariaDB has been removed
|
||||
in newer pretix releases.
|
||||
|
||||
In order to follow this guide, your pretix installation needs to be a version that fully supports MySQL/MariaDB. If you
|
||||
already upgraded to pretix 5.0 or later, downgrade back to the last 4.x release using ``pip``.
|
||||
|
||||
.. note:: We have tested this guide carefully, but we can't assume any liability for its correctness. The data loss
|
||||
risk should be low as long as pretix is not running while you do the migration. If you are a pretix Enterprise
|
||||
customer, feel free to reach out in advance if you want us to support you along the way.
|
||||
|
||||
Update database schema
|
||||
----------------------
|
||||
|
||||
Before you start, make sure your database schema is up to date. With a local installation::
|
||||
|
||||
# sudo -u pretix -s
|
||||
$ source /var/pretix/venv/bin/activate
|
||||
(venv)$ python -m pretix migrate
|
||||
|
||||
With a docker installation::
|
||||
|
||||
docker exec -it pretix.service pretix migrate
|
||||
|
||||
|
||||
Install PostgreSQL
|
||||
------------------
|
||||
|
||||
Now, install and set up a PostgreSQL server. For a local installation on Debian or Ubuntu, use::
|
||||
|
||||
# apt install postgresql
|
||||
|
||||
Having the database server installed, we still need a database and a database user. We can create these with any kind
|
||||
of database managing tool or directly on our database's shell. Please make sure that UTF8 is used as encoding for the
|
||||
best compatibility. You can check this with the following command::
|
||||
|
||||
# sudo -u postgres psql -c 'SHOW SERVER_ENCODING'
|
||||
|
||||
Without Docker
|
||||
""""""""""""""
|
||||
|
||||
For our standard manual installation, create the database and user like this::
|
||||
|
||||
# sudo -u postgres createuser pretix
|
||||
# sudo -u postgres createdb -O pretix pretix
|
||||
|
||||
With Docker
|
||||
"""""""""""
|
||||
|
||||
For our standard docker installation, create the database and user like this::
|
||||
|
||||
# sudo -u postgres createuser -P pretix
|
||||
# sudo -u postgres createdb -O pretix pretix
|
||||
|
||||
Make sure that your database listens on the network. If PostgreSQL on the same same host as docker, but not inside a docker container, we recommend that you listen on the Docker interface by changing the following line in ``/etc/postgresql/<version>/main/postgresql.conf``::
|
||||
|
||||
listen_addresses = 'localhost,172.17.0.1'
|
||||
|
||||
You also need to add a new line to ``/etc/postgresql/<version>/main/pg_hba.conf`` to allow network connections to this user and database::
|
||||
|
||||
host pretix pretix 172.17.0.1/16 md5
|
||||
|
||||
Restart PostgreSQL after you changed these files::
|
||||
|
||||
# systemctl restart postgresql
|
||||
|
||||
If you have a firewall running, you should also make sure that port 5432 is reachable from the ``172.17.0.1/16`` subnet.
|
||||
|
||||
Of course, instead of all this you can also run a PostgreSQL docker container and link it to the pretix container.
|
||||
|
||||
Stop pretix
|
||||
-----------
|
||||
|
||||
To prevent any more changes to your data, stop pretix from running. With a local installation::
|
||||
|
||||
# systemctl stop pretix-web pretix-worker
|
||||
|
||||
With docker::
|
||||
|
||||
# systemctl stop pretix
|
||||
|
||||
Change configuration
|
||||
--------------------
|
||||
|
||||
Change the database configuration in your ``/etc/pretix/pretix.cfg`` file::
|
||||
|
||||
[database]
|
||||
backend=postgresql
|
||||
name=pretix
|
||||
user=pretix
|
||||
password= ; only required for docker or remote database, can be kept empty for local auth
|
||||
host= ; set to 172.17.0.1 in docker setup, keep empty for local auth
|
||||
|
||||
|
||||
Create database schema
|
||||
-----------------------
|
||||
|
||||
To create the schema in your new PostgreSQL database, use the following commands. With a local installation::
|
||||
|
||||
# sudo -u pretix -s
|
||||
$ source /var/pretix/venv/bin/activate
|
||||
(venv)$ python -m pretix migrate
|
||||
|
||||
With docker::
|
||||
|
||||
# docker run --rm -v /var/pretix-data:/data -v /etc/pretix:/etc/pretix -v /var/run/redis:/var/run/redis pretix/standalone:stable migrate
|
||||
|
||||
|
||||
Migrate your data
|
||||
-----------------
|
||||
|
||||
Install ``pgloader``::
|
||||
|
||||
# apt install pgloader
|
||||
|
||||
.. note::
|
||||
|
||||
If you are using Ubuntu 20.04, the ``pgloader`` version from the repositories seems to be incompatible with PostgreSQL
|
||||
12+. You can install ``pgloader`` from the `PostgreSQL repositories`_ instead.
|
||||
See also `this discussion <https://github.com/pretix/pretix/issues/3090>`_.
|
||||
|
||||
Create a new file ``/tmp/pretix.load``, replacing the MySQL and PostgreSQL connection strings with the correct user names, passwords, and/or database names::
|
||||
|
||||
LOAD DATABASE
|
||||
FROM mysql://pretix:password@localhost/pretix -- replace with mysql://username:password@hostname/dbname
|
||||
INTO postgresql:///pretix -- replace with dbname
|
||||
|
||||
WITH data only, include no drop, truncate, disable triggers,
|
||||
create no indexes, drop indexes, reset sequences
|
||||
|
||||
ALTER SCHEMA 'pretix' RENAME TO 'public' -- replace pretix with the name of the MySQL database
|
||||
|
||||
ALTER TABLE NAMES MATCHING ~/.*/
|
||||
SET SCHEMA 'public'
|
||||
|
||||
SET timezone TO '+00:00'
|
||||
|
||||
SET PostgreSQL PARAMETERS
|
||||
maintenance_work_mem to '128MB',
|
||||
work_mem to '12MB';
|
||||
|
||||
Then, run::
|
||||
|
||||
# sudo -u postgres pgloader /tmp/pretix.load
|
||||
|
||||
The output should end with a table summarizing the results for every table. You can ignore warnings about type casts
|
||||
and missing constraints.
|
||||
|
||||
Afterwards, delete the file again::
|
||||
|
||||
# rm -rf /tmp/pretix.load
|
||||
|
||||
Start pretix
|
||||
------------
|
||||
|
||||
Stop your MySQL server as a verification step that you are no longer using it::
|
||||
|
||||
# systemctl stop mariadb
|
||||
|
||||
Then, restart pretix. With a local installation::
|
||||
|
||||
# systemctl start pretix-web pretix-worker
|
||||
|
||||
With a docker installation::
|
||||
|
||||
# systemctl start pretix
|
||||
|
||||
And you're done! After you've verified everything has been copied correctly, you can delete the old MySQL database.
|
||||
|
||||
.. note:: Don't forget to update your backup process to back up your PostgreSQL database instead of your MySQL database now.
|
||||
|
||||
Troubleshooting
|
||||
---------------
|
||||
|
||||
Peer authentication failed
|
||||
""""""""""""""""""""""""""
|
||||
|
||||
Sometimes you might see an error message like this::
|
||||
|
||||
django.db.utils.OperationalError: connection to server on socket "/var/run/postgresql/.s.PGSQL.5432" failed: FATAL: Peer authentication failed for user "pretix"
|
||||
|
||||
It is important to understand that PostgreSQL by default offers two types of authentication:
|
||||
|
||||
- **Peer authentication**, which works automatically based on the Linux user you are working as. This requires that
|
||||
the connection is made through a local socket (empty ``host=`` in ``pretix.cfg``) and the name of the PostgreSQL user
|
||||
and the Linux user are identical.
|
||||
|
||||
- Typically, you might run into this error if you accidentally execute ``python -m pretix`` commands as root instead
|
||||
of the ``pretix`` user.
|
||||
|
||||
- **Password authentication**, which requires a username and password and works over network connections. To force
|
||||
password authentication instead of peer authentication, set ``host=127.0.0.1`` in ``pretix.cfg``.
|
||||
|
||||
- You can alter the password on a PostgreSQL shell using the command ``ALTER USER pretix WITH PASSWORD '***';``.
|
||||
When creating a user with the ``createuser`` command, pass option ``-P`` to set a new password.
|
||||
|
||||
- Even with password authentication, PostgreSQL by default only allows local connections. To allow remote connections,
|
||||
you need to adjust both the ``listen_address`` configuration parameter as well as the ``pg_hba.conf`` file (see above
|
||||
for an example with the docker networking setup).
|
||||
|
||||
Database error: relation does not exist
|
||||
"""""""""""""""""""""""""""""""""""""""
|
||||
|
||||
If you see an error like this::
|
||||
|
||||
2023-04-17T19:20:47.744023Z ERROR Database error 42P01: relation "public.pretix_foobar" does not exist
|
||||
QUERY: ALTER TABLE public.pretix_foobar DROP CONSTRAINT IF EXISTS pretix_foobar_order_id_57e2cb41_fk_pretixbas CASCADE;
|
||||
2023-04-17T19:20:47.744023Z FATAL Failed to create the schema, see above.
|
||||
|
||||
The reason is most likely that in the past, you installed a pretix plugin that you no longer have installed. However,
|
||||
the database still contains tables of that plugin. If you want to keep the data, reinstall the plugin and re-run the
|
||||
``migrate`` step from above. If you want to get rid of the data, manually drop the table mentioned in the error message
|
||||
from your MySQL database::
|
||||
|
||||
# mysql -u root pretix
|
||||
mysql> DROP TABLE pretix_foobar;
|
||||
|
||||
Then, retry. You might see a new error message with a new table, which you can handle the same way.
|
||||
|
||||
Cleaning out a failed attempt
|
||||
"""""""""""""""""""""""""""""
|
||||
|
||||
You might want to clean your PostgreSQL database before you try again after an error. You can do so like this::
|
||||
|
||||
# sudo -u postgres psql pretix
|
||||
pretix=# DROP SCHEMA public CASCADE;
|
||||
pretix=# CREATE SCHEMA public;
|
||||
pretix=# ALTER SCHEMA public OWNER TO pretix;
|
||||
|
||||
``pgloader`` crashes with heap exhaustion error
|
||||
"""""""""""""""""""""""""""""""""""""""""""""""
|
||||
|
||||
On some larger databases, we've seen ``pgloader`` crash with error messages similar to this::
|
||||
|
||||
Heap exhausted during garbage collection: 16 bytes available, 48 requested.
|
||||
|
||||
Or this::
|
||||
|
||||
2021-01-04T21:31:17.367000Z ERROR A SB-KERNEL::HEAP-EXHAUSTED-ERROR condition without bindings for heap statistics. (If
|
||||
you did not expect to see this message, please report it.
|
||||
2021-01-04T21:31:17.382000Z ERROR The value
|
||||
NIL
|
||||
is not of type
|
||||
NUMBER
|
||||
when binding SB-KERNEL::X
|
||||
|
||||
The ``pgloader`` version distributed for Debian and Ubuntu is compiled with the ``SBCL`` compiler. If compiled with
|
||||
``CCL``, these bugs go away. Unfortunately, it is pretty hard to compile ``pgloader`` manually with ``CCL``. If you
|
||||
run into this, we therefore recommend using the docker container provided by the ``pgloader`` maintainers::
|
||||
|
||||
sudo docker run --rm -v /tmp:/tmp --network host -it dimitri/pgloader:ccl.latest pgloader /tmp/pretix.load
|
||||
|
||||
As peer authentication is not available from inside the container, this requires you to use password-based authentication
|
||||
in PostgreSQL (see above).
|
||||
|
||||
|
||||
.. _PostgreSQL repositories: https://wiki.postgresql.org/wiki/Apt
|
||||
@@ -1,236 +0,0 @@
|
||||
.. _`scaling`:
|
||||
|
||||
Scaling guide
|
||||
=============
|
||||
|
||||
Our :ref:`installation guide <installation>` only covers "small-scale" setups, by which we mostly mean
|
||||
setups that run on a **single (virtual) machine** and do not encounter large traffic peaks.
|
||||
|
||||
We do not offer an installation guide for larger-scale setups of pretix, mostly because we believe that
|
||||
there is no one-size-fits-all solution for this and the desired setup highly depends on your use case,
|
||||
the platform you run pretix on, and your technical capabilities. We do not recommend trying set up pretix
|
||||
in a multi-server environment if you do not already have experience with managing server clusters.
|
||||
|
||||
This document is intended to give you a general idea on what issues you will encounter when you scale up
|
||||
and what you should think of.
|
||||
|
||||
.. tip::
|
||||
|
||||
If you require more help on this, we're happy to help. Our pretix Enterprise support team has built
|
||||
and helped building, scaling and load-testing pretix installations at any scale and we're looking
|
||||
forward to work with you on fine-tuning your system. If you intend to sell **more than a thousand
|
||||
tickets in a very short amount of time**, we highly recommend reaching out and at least talking this
|
||||
through. Just get in touch at sales@pretix.eu!
|
||||
|
||||
Scaling reasons
|
||||
---------------
|
||||
|
||||
There are two main reasons for scaling up a pretix installation beyond a single server:
|
||||
|
||||
* **Availability:** Distributing pretix over multiple servers can allow you to survive failure of one or more single machines, leading to a higher uptime and reliability of your system.
|
||||
|
||||
* **Traffic and throughput:** Distributing pretix over multiple servers can allow you to process more web requests and ticket sales at the same time.
|
||||
|
||||
You are very unlikely to require scaling for other reasons, such as having too much data in your database.
|
||||
|
||||
Components
|
||||
----------
|
||||
|
||||
A pretix installation usually consists of the following components which run performance-relevant processes:
|
||||
|
||||
* ``pretix-web`` is the Django-based web application that serves all user interaction.
|
||||
|
||||
* ``pretix-worker`` is a Celery-based application that processes tasks that should be run asynchronously outside of the web application process.
|
||||
|
||||
* A **PostgreSQL database** keeps all the important data and processes the actual transactions.
|
||||
|
||||
* A **web server** that terminates TLS and HTTP connections and forwards them to ``pretix-web``. In some cases, e.g. when serving static files, the web servers might return a response directly. We recommend using ``nginx``.
|
||||
|
||||
* A **redis** server responsible for the communication between ``pretix-web`` and ``pretix-worker``, as well as for caching.
|
||||
|
||||
* A directory of **media files** such as user-uploaded files or generated files (tickets, invoices, …) that are created and used by ``pretix-web``, ``pretix-worker`` and the web server.
|
||||
|
||||
In the following, we will discuss the scaling behavior of every component individually. In general, you can run all of the components
|
||||
on the same server, but you can just as well distribute every component to its own server, or even use multiple servers for some single
|
||||
components.
|
||||
|
||||
.. warning::
|
||||
|
||||
When setting up your system, don't forget about security. In a multi-server environment,
|
||||
you need to take special care to ensure that no unauthorized access to your database
|
||||
is possible through the network and that it's not easy to wiretap your connections. We
|
||||
recommend a rigorous use of firewalls and encryption on all communications. You can
|
||||
ensure this either on an application level (such as using the TLS support in your
|
||||
database) or on a network level with a VPN solution.
|
||||
|
||||
Web server
|
||||
""""""""""
|
||||
|
||||
Your web server is at the very front of your installation. It will need to absorb all of the traffic, and it should be able to
|
||||
at least show a decent error message, even when everything else fails. Luckily, web servers are really fast these days, so this
|
||||
can be achieved without too much work.
|
||||
|
||||
We recommend reading up on tuning your web server for high concurrency. For nginx, this means thinking about the number of worker
|
||||
processes and the number of connections each worker process accepts. Double-check that TLS session caching works, because TLS
|
||||
handshakes can get really expensive.
|
||||
|
||||
During a traffic peak, your web server will be able to make use of more CPU resources, while memory usage will stay comparatively low,
|
||||
so if you invest in more hardware here, invest in more and faster CPU cores.
|
||||
|
||||
Make sure that pretix' static files (such as CSS and JavaScript assets) as well as user-uploaded media files (event logos, etc)
|
||||
are served directly by your web server and your web server caches them in-memory (nginx does it by default) and sets useful
|
||||
headers for client-side caching. As an additional performance improvement, you can turn of access logging for these types of files.
|
||||
If you want, you can even farm out serving static files to a different web server entirely and :ref:`configure pretix to reference
|
||||
them from a different URL <config-urls>`.
|
||||
|
||||
.. tip::
|
||||
|
||||
If you expect *really high traffic* for your very popular event, you might want to do some rate limiting on this layer, or,
|
||||
if you want to ensure a fair and robust first-come-first-served experience and prefer letting users wait over showing them
|
||||
errors, consider a queuing solution. We're happy to provide you with such systems, just get in touch at sales@pretix.eu.
|
||||
|
||||
pretix-web
|
||||
""""""""""
|
||||
|
||||
The ``pretix-web`` process does not carry any internal state and can be easily started on as many machines as you like, and you can
|
||||
use the load balancing features of your frontend web server to redirect to all of them.
|
||||
|
||||
You can adjust the number of processes in the ``gunicorn`` command line, and we recommend choosing roughly two times the number
|
||||
of CPU cores available. Under load, the memory consumption of ``pretix-web`` will stay comparatively constant, while the CPU usage
|
||||
will increase a lot. Therefore, if you can add more or faster CPU cores, you will be able to serve more users.
|
||||
|
||||
pretix-worker
|
||||
"""""""""""""
|
||||
|
||||
The ``pretix-worker`` process performs all operations that are not directly executed in the request-response-cycle of ``pretix-web``.
|
||||
Just like ``pretix-web`` you can easily start up as many instances as you want on different machines to share the work. As long as they
|
||||
all talk to the same redis server, they will all receive tasks from ``pretix-web``, work on them and post their result back.
|
||||
You can configure the number of threads that run tasks in parallel through the ``--concurrency`` command line option of ``celery``.
|
||||
|
||||
Just like ``pretix-web``, this process is mostly heavy on CPU, disk IO and network IO, although memory peaks can occur e.g. during the
|
||||
generation of large PDF files, so we recommend having some reserves here.
|
||||
|
||||
``pretix-worker`` performs a variety of tasks which are of different importance.
|
||||
Some of them are mission-critical and need to be run quickly even during high load (such as
|
||||
creating a cart or an order), others are irrelevant and can easily run later (such as
|
||||
distributing tickets on the waiting list). You can fine-tune the capacity you assign to each
|
||||
of these tasks by running ``pretix-worker`` processes that only work on a specific **queue**.
|
||||
For example, you could have three servers dedicated only to process order creations and one
|
||||
server dedicated only to sending emails. This allows you to set priorities and also protects
|
||||
you from e.g. a slow email server lowering your ticket throughput.
|
||||
|
||||
You can do so by specifying one or more queues on the ``celery`` command line of this process, such as ``celery -A pretix.celery_app worker -Q notifications,mail``. Currently,
|
||||
the following queues exist:
|
||||
|
||||
* ``checkout`` -- This queue handles everything related to carts and orders and thereby everything required to process a sale. This includes adding and deleting items from carts as well as creating and canceling orders.
|
||||
|
||||
* ``mail`` -- This queue handles sending of outgoing emails.
|
||||
|
||||
* ``notifications`` -- This queue handles the processing of any outgoing notifications, such as email notifications to admin users (except for the actual sending) or API notifications to registered webhooks.
|
||||
|
||||
* ``background`` -- This queue handles tasks that are expected to take long or have no human waiting for their result immediately, such as refreshing caches, re-generating CSS files, assigning tickets on the waiting list or parsing bank data files.
|
||||
|
||||
* ``default`` -- This queue handles everything else with "medium" or unassigned priority, most prominently the generation of files for tickets, invoices, badges, admin exports, etc.
|
||||
|
||||
Media files
|
||||
"""""""""""
|
||||
|
||||
Both ``pretix-web``, ``pretix-worker`` and in some cases your webserver need to work with
|
||||
media files. Media files are all files generated *at runtime* by the software. This can
|
||||
include files uploaded by the event organizers, such as the event logo, files uploaded by
|
||||
ticket buyers (if you use such features) or files generated by the software, such as
|
||||
ticket files, invoice PDFs, data exports or customized CSS files.
|
||||
|
||||
Those files are by default stored to the ``media/`` sub-folder of the data directory given
|
||||
in the ``pretix.cfg`` configuration file. Inside that ``media/`` folder, you will find a
|
||||
``pub/`` folder containing the subset of files that should be publicly accessible through
|
||||
the web server. Everything else only needs to be accessible by ``pretix-web`` and
|
||||
``pretix-worker`` themselves.
|
||||
|
||||
If you distribute ``pretix-web`` or ``pretix-worker`` across more than one machine, you
|
||||
**must** make sure that they all have access to a shared storage to read and write these
|
||||
files, otherwise you **will** run into errors with the user interface.
|
||||
|
||||
The easiest solution for this is probably to store them on a NFS server that you mount
|
||||
on each of the other servers.
|
||||
|
||||
Since we use Django's file storage mechanism internally, you can in theory also use an object-storage solution like Amazon S3, Ceph, or Minio to store these files, although we currently do not expose this through pretix' configuration file and this would require you to ship your own variant of ``pretix/settings.py`` and reference it through the ``DJANGO_SETTINGS_MODULE`` environment variable.
|
||||
|
||||
At pretix.eu, we use a custom-built `object storage cluster`_.
|
||||
|
||||
SQL database
|
||||
""""""""""""
|
||||
|
||||
One of the most critical parts of the whole setup is the SQL database -- and certainly the
|
||||
hardest to scale. Tuning relational databases is an art form, and while there's lots of
|
||||
material on it on the internet, there's not a single recipe that you can apply to every case.
|
||||
|
||||
As a general rule of thumb, the more resources you can give your databases, the better.
|
||||
Most databases will happily use all CPU cores available, but only use memory up to an amount
|
||||
you configure, so make sure to set this memory usage as high as you can afford. Having more
|
||||
memory available allows your database to make more use of caching, which is usually good.
|
||||
|
||||
Scaling your database to multiple machines needs to be treated with great caution. It's a
|
||||
good idea to have a replica of your database for availability reasons. In case your primary
|
||||
database server fails, you can easily switch over to the replica and continue working.
|
||||
|
||||
However, using database replicas for performance gain is much more complicated. When using
|
||||
replicated database systems, you are always trading in consistency or availability to get
|
||||
additional performance and the consequences of this can be subtle. It is important
|
||||
that you have a deep understanding of the semantics of your replication mechanism.
|
||||
|
||||
.. warning::
|
||||
|
||||
Using an off-the-shelf database proxy solution that redirects read queries to your
|
||||
replicas and write queries to your primary database **will lead to very nasty bugs.**
|
||||
|
||||
As an example, if you buy a ticket, pretix first needs to calculate how many tickets
|
||||
are left to sell. If this calculation is done on a database replica that lags behind
|
||||
even for fractions of a second, the decision to allow selling the ticket will be made
|
||||
on stale data and you can end up with more tickets sold than configured. Similarly,
|
||||
you could imagine situations leading to double payments etc.
|
||||
|
||||
If you do have a replica, you *can* tell pretix about it :ref:`in your configuration <config-replica>`.
|
||||
This way, pretix can offload complex read-only queries to the replica when it is safe to do so.
|
||||
As of pretix 2.7, this is mainly used for search queries in the backend and for rendering the
|
||||
product list and event lists in the frontend, but we plan on expanding this in the future.
|
||||
|
||||
Therefore, for now our clear recommendation is: Try to scale your database vertically and put
|
||||
it on the most powerful machine you have available.
|
||||
|
||||
redis
|
||||
"""""
|
||||
|
||||
While redis is a very important part that glues together some of the components, it isn't used
|
||||
heavily and can usually handle a fairly large pretix installation easily on a single modern
|
||||
CPU core.
|
||||
Having some memory available is good, e.g. if lots of tasks queue up during a traffic peak, but we wouldn't expect ever needing more than a gigabyte of it.
|
||||
|
||||
Feel free to set up a redis cluster for availability – but you probably won't need it for performance.
|
||||
|
||||
The limitations
|
||||
---------------
|
||||
|
||||
Up to a certain point, pretix scales really well. However, there are a few things that we consider
|
||||
even more important than scalability, and those are correctness and reliability. We want you to be
|
||||
able to trust that pretix will not sell more tickets than you intended or run into similar error
|
||||
cases.
|
||||
|
||||
Combined with pretix' flexibility and complexity, especially around vouchers and quotas, this creates
|
||||
some hard issues. In many cases, we need to fall back to event-global locking for some actions which
|
||||
are likely to run with high concurrency and cause harm.
|
||||
|
||||
For every event, only one of these locking actions can be run at the same time. Examples for this are
|
||||
adding products limited by a quota to a cart, adding items to a cart using a voucher or placing an order
|
||||
consisting of cart positions that don't have a valid reservation for much longer. In these cases, it is
|
||||
currently not realistically possible to exceed selling **approx. 500 orders per minute per event**, even
|
||||
if you add more hardware.
|
||||
If you have an unlimited number of tickets, we can apply fewer locking and we've reached **approx.
|
||||
1500 orders per minute per event** in benchmarks, although even more should be possible.
|
||||
|
||||
We're working on reducing the number of cases in which this is relevant and thereby improve the possible
|
||||
throughput. If you want to use pretix for an event with 10,000+ tickets that are likely to be sold out
|
||||
within minutes, please get in touch to discuss possible solutions. We'll work something out for you!
|
||||
|
||||
|
||||
.. _object storage cluster: https://behind.pretix.eu/2018/03/20/high-available-cdn/
|
||||
@@ -1,83 +0,0 @@
|
||||
.. _`update_notes`:
|
||||
|
||||
Update notes
|
||||
============
|
||||
|
||||
pretix receives regular feature and bugfix updates and we highly encourage you to always update to
|
||||
the latest version for maximum quality and security. Updates are announces on our `blog`_. There are
|
||||
usually 10 feature updates in a year, so you can expect a new release almost every month.
|
||||
|
||||
Pure bugfix releases are only issued in case of very critical bugs or security vulnerabilities. In these
|
||||
case, we'll publish bugfix releases for the last three stable release branches.
|
||||
|
||||
Compatibility to plugins and in very rare cases API clients may break. For in-depth details on the
|
||||
API changes of every version, please refer to the release notes published on our blog.
|
||||
|
||||
Upgrade steps
|
||||
-------------
|
||||
|
||||
For the actual upgrade, you can usually just follow the steps from the installation guide for :ref:`manual installations <manual_updates>`
|
||||
or :ref:`docker installations <docker_updates>` respectively.
|
||||
Generally, it is always strongly recommended to perform a :ref:`backup <backups>` first.
|
||||
It is possible to skip versions during updates, although we recommend not skipping over major version numbers
|
||||
(i.e. if you want to go from 2.4 to 4.4, first upgrade to 3.0, then upgrade to 4.0, then to 4.4).
|
||||
|
||||
In addition to these standard update steps, the following list issues steps that should be taken when you upgrade
|
||||
to specific versions for pretix. If you're skipping versions, please read the instructions for every version in
|
||||
between as well.
|
||||
|
||||
Upgrade to 3.17.0 or newer
|
||||
""""""""""""""""""""""""""
|
||||
|
||||
pretix 3.17 introduces a dependency on ``nodejs``, so you should install it on your system::
|
||||
|
||||
# apt install nodejs npm
|
||||
|
||||
Upgrade to 4.4.0 or newer
|
||||
"""""""""""""""""""""""""
|
||||
|
||||
pretix 4.4 introduces a new data structure to store historical financial data. If you already have existing
|
||||
data in your database, you will need to back-fill this data or you might get incorrect reports! This is not
|
||||
done automatically as part of the usual update steps since it can take a while on large databases and you might
|
||||
want to do it in parallel while the system is already running again. Please execute the following command::
|
||||
|
||||
(venv)$ python -m pretix create_order_transactions
|
||||
|
||||
Or, with a docker installation::
|
||||
|
||||
$ docker exec -it pretix.service pretix create_order_transactions
|
||||
|
||||
Upgrade to 2023.6.0 or newer
|
||||
""""""""""""""""""""""""""""
|
||||
|
||||
MariaDB and MySQL are no longer supported.
|
||||
|
||||
Upgrade to 2023.8.0 or newer
|
||||
""""""""""""""""""""""""""""
|
||||
|
||||
PostgreSQL 11 is now required.
|
||||
|
||||
Upgrade to 2023.9.0 or newer
|
||||
""""""""""""""""""""""""""""
|
||||
|
||||
This release includes a migration that changes the `id` column of all core database tables from `integer`
|
||||
to `bigint`. If you have a large database, the migration step of the upgrade might take significantly longer than
|
||||
usual, so plan the update accordingly.
|
||||
|
||||
The default value for the `registration` setting in `pretix.cfg` has changed to `false`.
|
||||
|
||||
Upgrade to 2023.10.0 or newer
|
||||
"""""""""""""""""""""""""""""
|
||||
|
||||
This release includes a migration that changes retroactively fills an `organizer` column in the table
|
||||
`pretixbase_logentry`. If you have a large database, the migration step of the upgrade might take significantly
|
||||
longer than usual, so plan the update accordingly.
|
||||
|
||||
Upgrade to 2024.7.0 or newer
|
||||
"""""""""""""""""""""""""""""
|
||||
|
||||
This release includes a migration that changes how sales channels are referred on orders.
|
||||
If you have a large database, the migration step of the upgrade might take significantly longer than usual, so plan
|
||||
the update accordingly.
|
||||
|
||||
.. _blog: https://pretix.eu/about/en/blog/
|
||||
@@ -1,7 +1,7 @@
|
||||
Badges
|
||||
======
|
||||
|
||||
The badges plugin provides a HTTP API that exposes the various layouts used to generate PDF badges.
|
||||
The built-in badges plugin provides a HTTP API that exposes the various layouts used to generate PDF badges.
|
||||
|
||||
Resource description
|
||||
--------------------
|
||||
@@ -1,7 +1,7 @@
|
||||
Bank transfer HTTP API
|
||||
======================
|
||||
Bank transfer
|
||||
=============
|
||||
|
||||
The banktransfer plugin provides a HTTP API that `pretix-banktool`_ uses to send bank
|
||||
The built-in banktransfer plugin provides a HTTP API that `pretix-banktool`_ uses to send bank
|
||||
transactions to the pretix server. This API is integrated with the regular :ref:`rest-api`
|
||||
and therefore follows the conventions listed there.
|
||||
|
||||
@@ -1,6 +1,8 @@
|
||||
Campaigns
|
||||
=========
|
||||
|
||||
.. note:: This API is only available when the plugin **pretix-campaigns** is installed (pretix Hosted and Enterprise only).
|
||||
|
||||
The campaigns plugin provides a HTTP API that allows you to create new campaigns.
|
||||
|
||||
Resource description
|
||||
@@ -1,6 +1,8 @@
|
||||
Certificates of attendance
|
||||
==========================
|
||||
|
||||
.. note:: This API is only available when the plugin **pretix-certificates** is installed (pretix Hosted and Enterprise only).
|
||||
|
||||
The certificates plugin provides a HTTP API that allows you to download the certificate for a specific attendee.
|
||||
|
||||
|
||||
@@ -1,6 +1,8 @@
|
||||
Digital content
|
||||
===============
|
||||
|
||||
.. note:: This API is only available when the plugin **pretix-digital** is installed (pretix Hosted and Enterprise only).
|
||||
|
||||
URL interpolation and JWT authentication
|
||||
----------------------------------------
|
||||
|
||||
@@ -1,6 +1,8 @@
|
||||
Exhibitors
|
||||
==========
|
||||
|
||||
.. note:: This API is only available when the plugin **pretix-exhibitors** is installed (pretix Hosted and Enterprise only).
|
||||
|
||||
The exhibitors plugin allows to manage exhibitors at your trade show or conference. After signing up your exhibitors
|
||||
in the system, you can assign vouchers to exhibitors and give them access to the data of these vouchers. The exhibitors
|
||||
module is also the basis of the pretixLEAD lead scanning application.
|
||||
@@ -1,6 +1,8 @@
|
||||
Secrets Import
|
||||
==============
|
||||
|
||||
.. note:: This API is only available when the plugin **pretix-secrets-import** is installed (pretix Hosted and Enterprise only).
|
||||
|
||||
Usually, pretix generates ticket secrets (i.e. the QR code used for scanning) itself. You can read more about this
|
||||
process at :ref:`secret_generators`.
|
||||
|
||||
@@ -22,6 +22,7 @@ at :ref:`plugin-docs`.
|
||||
questions
|
||||
question_options
|
||||
quotas
|
||||
seats
|
||||
orders
|
||||
invoices
|
||||
vouchers
|
||||
@@ -43,8 +44,16 @@ at :ref:`plugin-docs`.
|
||||
exporters
|
||||
scheduled_exports
|
||||
shredders
|
||||
banktransfer
|
||||
ticketoutputpdf
|
||||
badges
|
||||
sendmail_rules
|
||||
auto_checkin_rules
|
||||
campaigns
|
||||
certificates
|
||||
digital
|
||||
exhibitors
|
||||
imported_secrets
|
||||
shipping
|
||||
billing_invoices
|
||||
billing_var
|
||||
seats
|
||||
|
||||
@@ -1,6 +1,8 @@
|
||||
Shipping
|
||||
========
|
||||
|
||||
.. note:: This API is only available when the plugin **pretix-shipping** is installed (pretix Hosted and Enterprise only).
|
||||
|
||||
The shipping plugin provides a HTTP API that exposes the various layouts used to generate PDF badges.
|
||||
|
||||
Shipping address resource
|
||||
@@ -1,7 +1,7 @@
|
||||
PDF ticket output
|
||||
=================
|
||||
|
||||
The PDF ticket output plugin provides a HTTP API that exposes the various layouts used
|
||||
The build-in PDF ticket output plugin provides a HTTP API that exposes the various layouts used
|
||||
to generate PDF tickets.
|
||||
|
||||
Resource description
|
||||
14
doc/conf.py
@@ -69,7 +69,7 @@ master_doc = 'index'
|
||||
|
||||
# General information about the project.
|
||||
project = 'pretix'
|
||||
copyright = '2014-{}, Raphael Michel'.format(date.today().year)
|
||||
copyright = '2014-{}, rami.io GmbH'.format(date.today().year)
|
||||
|
||||
# The version info for the project you're documenting, acts as replacement for
|
||||
# |version| and |release|, also used in various other places throughout the
|
||||
@@ -233,8 +233,8 @@ latex_elements = {
|
||||
# (source start file, target name, title,
|
||||
# author, documentclass [howto, manual, or own class]).
|
||||
latex_documents = [
|
||||
('index', 'pretix.tex', 'pretix Documentation',
|
||||
'Raphael Michel', 'manual'),
|
||||
('index', 'pretix.tex', 'pretix Developer Documentation',
|
||||
'rami.io GmbH', 'manual'),
|
||||
]
|
||||
|
||||
# The name of an image file (relative to this directory) to place at the top of
|
||||
@@ -263,8 +263,8 @@ latex_documents = [
|
||||
# One entry per manual page. List of tuples
|
||||
# (source start file, name, description, authors, manual section).
|
||||
man_pages = [
|
||||
('index', 'pretix', 'pretix Documentation',
|
||||
['Raphael Michel'], 1)
|
||||
('index', 'pretix', 'pretix Developer Documentation',
|
||||
['rami.io GmbH'], 1)
|
||||
]
|
||||
|
||||
# If true, show URL addresses after external links.
|
||||
@@ -277,8 +277,8 @@ man_pages = [
|
||||
# (source start file, target name, title, author,
|
||||
# dir menu entry, description, category)
|
||||
texinfo_documents = [
|
||||
('index', 'pretix', 'pretix Documentation',
|
||||
'Raphael Michel', 'pretix', 'One line description of project.',
|
||||
('index', 'pretix', 'pretix Developer Documentation',
|
||||
'rami.io GmbH', 'pretix', 'One line description of project.',
|
||||
'Miscellaneous'),
|
||||
]
|
||||
|
||||
|
||||
@@ -4,10 +4,6 @@ Table of contents
|
||||
.. toctree::
|
||||
:maxdepth: 3
|
||||
|
||||
user/index
|
||||
admin/index
|
||||
api/index
|
||||
development/index
|
||||
plugins/index
|
||||
license/faq
|
||||
|
||||
|
||||
@@ -1,5 +1,5 @@
|
||||
Developer documentation
|
||||
=======================
|
||||
Plugin & core development
|
||||
=========================
|
||||
|
||||
.. toctree::
|
||||
:maxdepth: 2
|
||||
|
||||
@@ -5,7 +5,7 @@ Development setup
|
||||
|
||||
This tutorial helps you to get started hacking with pretix on your own computer. You need this to
|
||||
be able to contribute to pretix, but it might also be helpful if you want to write your own plugins.
|
||||
If you want to install pretix on a server for actual usage, go to the :ref:`admindocs` instead.
|
||||
If you want to install pretix on a server for actual usage, go to the [administrator documentation](https://docs.pretix.eu/self-hosting/) instead.
|
||||
|
||||
Obtain a copy of the source code
|
||||
--------------------------------
|
||||
@@ -18,7 +18,7 @@ External Dependencies
|
||||
---------------------
|
||||
Your should install the following on your system:
|
||||
|
||||
* Python 3.5 or newer
|
||||
* Python 3.9 or newer
|
||||
* ``pip`` for Python 3 (Debian package: ``python3-pip``)
|
||||
* ``python-dev`` for Python 3 (Debian package: ``python3-dev``)
|
||||
* On Debian/Ubuntu: ``python-venv`` for Python 3 (Debian package: ``python3-venv``)
|
||||
@@ -33,7 +33,7 @@ Your should install the following on your system:
|
||||
Your local python environment
|
||||
-----------------------------
|
||||
|
||||
Please execute ``python -V`` or ``python3 -V`` to make sure you have Python 3.4
|
||||
Please execute ``python -V`` or ``python3 -V`` to make sure you have Python 3.9
|
||||
(or newer) installed. Also make sure you have pip for Python 3 installed, you can
|
||||
execute ``pip3 -V`` to check. Then use Python's internal tools to create a virtual
|
||||
environment and activate it for your current session::
|
||||
|
||||
@@ -1 +1,29 @@
|
||||
<svg xmlns="http://www.w3.org/2000/svg" xml:space="preserve" width="254.156" height="109.594" version="1.1"><g transform="scale(1.9856)"><path d="M36.29 23.21c-.35 0-.61.06-.83.13v8.29c.19.06.45.13.77.13 1.73 0 2.46-1.44 2.46-4.26s-.64-4.29-2.4-4.29z" fill="#f8f8f8"/><path d="M61.22 23.15c-1.44 0-2.21 1.31-2.08 3.71l3.9-.58c.03-2.11-.58-3.14-1.82-3.14z" fill="#f8f8f8"/><path d="M127.39 17.1c.35-.03.61-.29.61-.64V.64c0-.35-.29-.64-.64-.64H75.94v2.48c0 .62-.5 1.12-1.12 1.12-.62 0-1.12-.5-1.12-1.12V0H.64C.29 0 0 .29 0 .64v15.82c0 .35.26.61.61.64 5.47.32 9.82 4.86 9.82 10.43 0 5.57-4.35 10.08-9.82 10.37-.35.03-.61.29-.61.64v15.82c0 .35.29.64.64.64h73.22-.16v-2.48c0-.63.49-1.12 1.12-1.12.63 0 1.12.5 1.12 1.12V55h-.16 51.58c.35 0 .64-.29.64-.64V38.54c0-.35-.26-.61-.61-.64-5.47-.32-9.82-4.83-9.82-10.4s4.35-10.11 9.82-10.4zM37.41 34.57c-.86 0-1.6-.1-1.95-.19v5.54H30.6v-18.5c1.31-.61 3.07-1.06 5.73-1.06 4.26 0 7.17 2.27 7.17 7.1 0 4.35-2.53 7.1-6.08 7.1zm15.58-10.78c-.9-.45-1.76-.45-2.4-.22v10.85h-4.86V21.43c1.41-.7 3.55-1.09 6.69-1.06.45 0 .93.03 1.41.06L53 23.79Zm14.56 4.26-8.03 1.12c.32 1.47 1.09 2.21 2.85 2.21 1.63 0 2.91-.35 3.68-.74l1.09 2.98c-1.22.58-2.82 1.06-5.38 1.06-4.51 0-6.88-3.04-6.88-7.17s2.21-7.1 6.53-7.1c4.35-.03 6.4 2.98 6.14 7.65zm8.38 18.56c0 .62-.5 1.12-1.12 1.12-.62 0-1.12-.5-1.12-1.12v-5.12c0-.62.5-1.12 1.12-1.12.62 0 1.12.52 1.12 1.12zm0-11.07c0 .6-.52 1.12-1.12 1.12-.6 0-1.12-.52-1.12-1.12v-5.12c0-.63.49-1.12 1.12-1.12.63 0 1.12.5 1.12 1.12zm0-11.01c0 .62-.5 1.12-1.12 1.12-.62 0-1.12-.5-1.12-1.12v-5.12c0-.62.5-1.12 1.12-1.12.62 0 1.12.52 1.12 1.12zm0-11.07c0 .6-.52 1.12-1.12 1.12-.6 0-1.12-.52-1.12-1.12V8.34c0-.63.49-1.12 1.12-1.12.63 0 1.12.5 1.12 1.12zM90.11 23.8h-2.02v6.18c0 1.02.35 1.41 1.09 1.41.35 0 .54-.06.93-.19v2.98c-.35.19-1.22.48-2.34.48-3.1 0-4.51-1.89-4.51-4.26v-6.59h-1.44v-3.17h1.44v-2.82l4.86-1.22v4.03h1.98v3.17zm7.07 10.62h-4.86V20.66h4.86zm-2.43-15.58c-1.38 0-2.5-.99-2.5-2.21s1.12-2.18 2.5-2.18 2.53.96 2.53 2.18c0 1.22-1.12 2.21-2.53 2.21zm12.35 15.58-1.76-3.81h-.06l-1.82 3.81h-4.9l4.32-7.1-3.87-6.66h5.06l1.66 3.46h.06l1.82-3.46h4.51l-4 6.37 4.38 7.42-5.41-.03z" fill="#f8f8f8"/></g></svg>
|
||||
<?xml version="1.0" encoding="UTF-8"?>
|
||||
<svg id="Ebene_1" xmlns="http://www.w3.org/2000/svg" viewBox="0 0 128 69">
|
||||
<defs>
|
||||
<style>.cls-1{fill:#f8f8f8;}</style>
|
||||
</defs>
|
||||
<path class="cls-1"
|
||||
d="m45.94,31.18l1.72,12.27,4.59-.65-1.44-10.24c.57-.3,1.39-.41,2.3-.11l.34-3.28c-.46.03-.91.07-1.34.13-2.97.39-4.94,1.03-6.17,1.88Z"/>
|
||||
<path class="cls-1"
|
||||
d="m85.33,20.99l-4.43,1.79.37,2.66-1.36.19.42,2.99,1.36-.19.87,6.22c.31,2.24,1.89,3.83,4.83,3.42,1.06-.15,1.84-.54,2.14-.76l-.39-2.81c-.35.17-.52.26-.85.3-.69.1-1.08-.22-1.21-1.19l-.82-5.83,1.87-.26h.03s-.42-3-.42-3l-1.87.26-.54-3.81Z"/>
|
||||
<rect class="cls-1" x="90.72" y="23.89" width="4.64" height="13.12" transform="translate(-3.33 13.25) rotate(-8)"/>
|
||||
<path class="cls-1"
|
||||
d="m91.3,18.09c-1.3.18-2.23,1.24-2.07,2.39s1.35,1.94,2.65,1.75,2.26-1.27,2.09-2.42-1.35-1.91-2.68-1.72Z"/>
|
||||
<polygon class="cls-1"
|
||||
points="108.53 21.65 104.27 22.25 103.01 25.75 102.95 25.76 100.92 22.72 96.15 23.39 100.69 29.16 97.55 36.44 102.17 35.79 103.39 31.95 103.45 31.94 105.62 35.31 105.62 35.34 110.73 34.62 105.6 28.19 108.53 21.65"/>
|
||||
<path class="cls-1"
|
||||
d="m36.92,31.44c-2.51.35-4.11,1.01-5.27,1.76l2.45,17.46,4.59-.65-.73-5.23c.35.04,1.05.04,1.87-.08,3.35-.47,5.38-3.41,4.8-7.51-.64-4.56-3.69-6.32-7.71-5.76Zm1.42,10.77c-.3.04-.55.02-.74-.02l-1.1-7.83c.2-.09.44-.18.77-.23,1.66-.23,2.45,1.01,2.84,3.73s-.13,4.12-1.76,4.35Z"/>
|
||||
<path class="cls-1"
|
||||
d="m60.61,28.14c-4.08.57-5.77,3.68-5.22,7.57s3.19,6.45,7.45,5.86c2.42-.34,3.86-1.01,4.94-1.71l-1.42-2.67c-.67.46-1.84.97-3.38,1.18-1.66.23-2.48-.36-2.98-1.71l7.44-2.12c-.38-4.45-2.71-7.01-6.82-6.41Zm-1.29,6.4c-.44-2.25.11-3.59,1.47-3.78,1.18-.17,1.89.72,2.14,2.72l-3.61,1.06Z"/>
|
||||
<path class="cls-1"
|
||||
d="m122.48,16.27c.33-.08.54-.35.49-.68l-2.1-14.94c-.05-.33-.36-.57-.69-.52L.53,16.94c-.33.05-.57.36-.52.69l2.1,14.94c.05.33.32.54.66.52,5.21-.42,9.92,3.29,10.66,8.55s-2.77,10.1-7.9,11.09c-.33.08-.54.35-.49.68l2.1,14.94c.05.33.36.57.69.52l119.65-16.82c.33-.05.57-.36.52-.69l-2.1-14.94c-.05-.33-.32-.54-.66-.52-5.21.42-9.92-3.26-10.66-8.52s2.77-10.13,7.9-11.12Zm-9.71,11.38c.81,5.77,5.72,10.04,11.47,10.13l1.78,12.64-47.53,6.68-.33-2.34c-.07-.48-.52-.82-1-.75s-.82.5-.75,1l.33,2.34-67.95,9.55-1.78-12.64c5.5-1.64,9.05-7.06,8.24-12.87s-5.73-10.07-11.47-10.16l-1.78-12.64,67.95-9.55.33,2.34c.07.48.52.82,1,.75s.82-.52.75-1l-.33-2.34,47.53-6.68,1.78,12.64c-5.5,1.64-9.05,7.09-8.23,12.9Z"/>
|
||||
<path class="cls-1"
|
||||
d="m75.82,44.49c-.48.07-.82.52-.75,1l.59,4.23c.07.48.52.82,1,.75s.82-.52.75-1l-.59-4.23c-.07-.47-.53-.82-1-.75Z"/>
|
||||
<path class="cls-1"
|
||||
d="m74.46,34.86c-.5.07-.82.5-.75,1l.59,4.23c.07.47.53.82,1,.75s.82-.53.75-1l-.59-4.23c-.07-.48-.52-.82-1-.75Z"/>
|
||||
<path class="cls-1"
|
||||
d="m73.11,25.23c-.48.07-.82.52-.75,1l.59,4.23c.07.48.52.82,1,.75s.82-.52.75-1l-.59-4.23c-.07-.47-.53-.82-1-.75Z"/>
|
||||
<path class="cls-1"
|
||||
d="m71.76,15.6c-.5.07-.82.5-.75,1l.59,4.23c.07.47.53.82,1,.75s.82-.53.75-1l-.59-4.23c-.07-.48-.52-.82-1-.75Z"/>
|
||||
</svg>
|
||||
|
Before Width: | Height: | Size: 2.1 KiB After Width: | Height: | Size: 3.0 KiB |
@@ -1,143 +0,0 @@
|
||||
ePayBL
|
||||
======
|
||||
|
||||
.. note::
|
||||
|
||||
Since ePayBL is only available to german federal, provincial and communal entities, the following page is also
|
||||
only provided in german. Should you require assistance with ePayBL and do not speak this language, please feel free
|
||||
reach out to support@pretix.eu.
|
||||
|
||||
|
||||
Einführung
|
||||
----------
|
||||
|
||||
.. note::
|
||||
|
||||
Sollten Sie lediglich schnell entscheiden wollen, welcher Kontierungsmodus in den Einstellungen des pretix
|
||||
ePayBL-plugins gewählt werden soll, so springen Sie direkt zur Sektion :ref:`Kontierungsmodus`.
|
||||
|
||||
|
||||
`ePayBL`_ - das ePayment-System von Bund und Länder - ist das am weitesten verbreitete Zahlungssystem für Bundes-, Länder-
|
||||
sowie kommunale Aufgabenträger. Während es nur wie eines von vielen anderen Zahlungssystemen scheint, so bietet es
|
||||
seinen Nutzern besondere Vorteile, wie die automatische Erfassung von Zahlungsbelegen, dem Übertragen von Buchungen in
|
||||
Haushaltskassen/-systeme sowie die automatische Erfassung von Kontierungen und Steuermerkmalen.
|
||||
|
||||
Rein technisch gesehen ist ePayBL hierbei nicht ein eigenständiger Zahlungsdienstleister sondern nur ein eine Komponente
|
||||
im komplexen System, dass die Zahlungsabwicklung für Kommunen und Behörden ist.
|
||||
|
||||
Im folgenden der schematische Aufbau einer Umgebung, in welcher ePayBL zum Einsatz kommt:
|
||||
|
||||
.. figure:: img/epaybl_flowchart.png
|
||||
:class: screenshot
|
||||
|
||||
Quelle: Integrationshandbuch ePayBL-Konnektor, DResearch Digital Media Systems GmbH
|
||||
|
||||
|
||||
In diesem Schaubild stellt pretix, bzw. die von Ihnen als Veranstalter angelegten Ticketshops, das Fachverfahren dar.
|
||||
|
||||
ePayBL stellt das Bindeglied zwischen den Fachverfahren, Haushaltssystemen und dem eigentlichen Zahlungsdienstleister,
|
||||
dem sog. ZV-Provider dar. Dieser ZV-Provider ist die Stelle, welche die eigentlichen Kundengelder einzieht und an den
|
||||
Händler auszahlt. Das Gros der Zahlungsdienstleister unterstützt pretix hierbei auch direkt; sprich: Sollten Sie die
|
||||
Anbindung an Ihre Haushaltssysteme nicht benötigen, kann eine direkte Anbindung in der Regel ebenso - und dies bei meist
|
||||
vermindertem Aufwand - vorgenommen werden.
|
||||
|
||||
In der Vergangenheit zeigte sich jedoch schnell, dass nicht jeder IT-Dienstleister immer sofort die neueste Version von
|
||||
ePayBL seinen Nutzern angeboten hat. Die Gründe hierfür sind mannigfaltig: Von fest vorgegebenen Update-Zyklen bis hin
|
||||
zu Systeme mit speziellen Anpassungen, kann leider nicht davon ausgegangen werden, dass alle ePayBL-Systeme exakt gleich
|
||||
ansprechbar sind - auch wenn es sich dabei eigentlich um einen standardisierten Dienst handelt.
|
||||
|
||||
Aus diesem Grund gibt es mit dem ePayBL-Konnektor eine weitere Abstraktionsschicht welche optional zwischen den
|
||||
Fachverfahren und dem ePayBL-Server sitzt. Dieser Konnektor wird so gepflegt, dass er zum einen eine dauerhaft
|
||||
gleichartige Schnittstelle den Fachverfahren bietet aber gleichzeitig auch mit jeder Version des ePayBL-Servers
|
||||
kommunizieren kann - egal wie neu oder alt, wie regulär oder angepasst diese ist.
|
||||
|
||||
Im Grunde müsste daher eigentlich immer gesagt werden, dass pretix eine Anbindung an den ePayBL-Konnektor bietet; nicht
|
||||
an "ePayBL" oder den "ePayBL-Server". Diese Unterscheidung kann bei der Ersteinrichtung und Anforderung von Zugangsdaten
|
||||
von Relevanz sein. Da in der Praxis jedoch beide Begriffe gleichbedeutend genutzt werden, wird im Folgenden auch nur von
|
||||
einer ePayBL-Anbindung die Rede sein - auch wenn explizit der Konnektor gemeint ist.
|
||||
|
||||
|
||||
.. _`Kontierungsmodus`:
|
||||
|
||||
Kontierungsmodus
|
||||
----------------
|
||||
|
||||
ePayBL ist ein Produkt, welches für die Abwicklung von Online-Zahlungsvorgängen in der Verwaltung geschaffen wurde. Ein
|
||||
Umfeld, in dem klar definiert ist, was ein Kunde gerade bezahlt und wohin das Geld genau fließt. Diese Annahmen lassen
|
||||
sich in einem Ticketshop wie pretix jedoch nur teilweise genauso abbilden.
|
||||
|
||||
Die ePayBL-Integration für pretix bietet daher zwei unterschiedliche Modi an, wie Buchungen erfasst und an ePayBL und
|
||||
damit auch an die dahinterliegenden Haushaltssysteme gemeldet werden können.
|
||||
|
||||
Kontierung pro Position/Artikel
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
Dieser Modus versucht den klassischen, behördentypischen ePayBL-Zahlungsvorgang abzubilden: Jede einzelne Position, die
|
||||
ein Kunde in den Warenkorb legt, wird auch genauso 1:1 an ePayBL und die Hintergrundsysteme übermittelt.
|
||||
|
||||
Hierbei muss zwingend auch für jede Position ein Kennzeichen für Haushaltsstelle und Objektnummer, sowie optional ein
|
||||
Kontierungsobjekt (``HREF``; bspw. ``stsl=Steuerschlüssel;psp=gsb:Geschäftsbereich,auft:Innenauftrag,kst:Kostenstelle;``
|
||||
) übermittelt werden.
|
||||
|
||||
Diese Daten sind vom Veranstalter entsprechend für jeden in der Veranstaltung angelegten Artikel innerhalb des Tabs
|
||||
"Zusätzliche Einstellungen" der Produkteinstellungen zu hinterlegen.
|
||||
|
||||
Während diese Einstellung eine größtmögliche Menge an Kontierungsdaten überträgt und auch ein separates Verbuchen von
|
||||
Leistungen auf unterschiedliche Haushaltsstellen erlaubt, so hat diese Option auch einen großen Nachteil: Der Kunde kann
|
||||
nur eine Zahlung für seine Bestellung leisten.
|
||||
|
||||
Während sich dies nicht nach einem großen Problem anhört, so kann dies beim Kunden zu Frust führen. pretix bietet die
|
||||
Option an, dass ein Veranstalter eine Bestellung jederzeit verändern kann: Ändern von Preisen von Positionen in einer
|
||||
aufgegebenen Bestellung, Zubuchen und Entfernen von Bestellpositionen, etc. Hat der Kunde seine ursprüngliche Bestellung
|
||||
jedoch schon bezahlt, kann pretix nicht mehr die komplette Bestellung mit den passenden Kontierungen übertragen - es
|
||||
müsste nur ein Differenz-Abbild zwischen Ursprungsbestellung und aktueller Bestellung übertragen werden. Aber auch wenn
|
||||
eine "Nachmeldung" möglich wäre, so wäre ein konkretes Auflösen für was jetzt genau gezahlt wird, nicht mehr möglich.
|
||||
|
||||
Daher gilt bei der Nutzung der Kontierung pro Position/Artikel: Der Kunde kann nur eine (erfolgreiche) Zahlung auf seine
|
||||
Bestellung leisten.
|
||||
|
||||
Eine weitere Einschränkung dieses Modus ist, dass aktuell keine Gebühren-Positionen (Versandkosten, Zahlungs-, Storno-
|
||||
oder Servicegebühren) in diesem Modus übertragen werden können. Bitte wenden Sie sich an uns, wenn Sie diese
|
||||
Funktionalität benötigen.
|
||||
|
||||
|
||||
Kontierung pro Zahlvorgang
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
Dieser Modus verabschiedet sich vom behördlichen "Jede Position gehört genau zu einem Haushaltskonto und muss genau
|
||||
zugeordnet werden". Stattdessen werden alle Bestellpositionen - inklusive eventuell definierter Gebühren - vermengt und
|
||||
nur als ein großer Warenkorb, genauer gesagt: eine einzige Position an ePayBL sowie die Hintergrundsysteme gemeldet.
|
||||
|
||||
Während im "pro Postion/Artikel"-Modus jeder Artikel einzeln übermittelt wird und damit auch korrekt pro Artikel der
|
||||
jeweilige Brutto- und Nettopreis, sowie der anfallende Steuerbetrag und ein Steuerkennzeichen (mit Hilfe des optionalen
|
||||
``HREF``-Attributs) übermittelt werden, ist dies im "pro Zahlvorgang"-Modus nicht möglich.
|
||||
|
||||
Stattdessen übermittelt pretix nur einen Betrag für den gesamten Warenkorb: Bruttopreis == Nettopreis. Der Steuerbetrag
|
||||
wird hierbei als 0 übermittelt.
|
||||
|
||||
Die Angabe einer Haushaltsstelle und Objektnummer, sowie optional der ``HREF``-Kontierungsinformationen ist jedoch
|
||||
weiterhin notwendig - allerdings nicht mehr individuell für jeden Artikel/jede Position sondern nur für die gesamte
|
||||
Bestellung. Diese Daten sind direkt in den ePayBL-Einstellungen der Veranstaltung unter Einstellungen -> Zahlung ->
|
||||
ePayBL vorzunehmen
|
||||
|
||||
In der Praxis bedeutet dies, dass in einem angeschlossenen Haushaltssystem nicht nachvollzogen kann, welche Positionen
|
||||
konkret erworben und bezahlt wurden - stattdessen kann nur der Fakt, dass etwas verkauft wurde erfasst werden.
|
||||
|
||||
Je nach Aufbau und Vorgaben der Finanzbuchhaltung kann dies jedoch ausreichend sein - wenn bspw. eine Ferienfahrt
|
||||
angeboten wird und seitens der Haushaltssysteme nicht erfasst werden muss, wie viel vom Gesamtbetrag einer Bestellung
|
||||
auf die Ferienfahrt an sich, auf einen Zubringerbus und einen Satz Bettwäsche entfallen ist, sondern (vereinfacht
|
||||
gesagt) es ausreichend ist, dass "Eine Summe X für die Haushaltsstelle/Objektnummer geflossen ist".
|
||||
|
||||
Dieser Modus der Kontierung bietet Ihnen auch als Vorteil gegenüber dem vorhergehenden an, dass die Bestellungen der
|
||||
Kunden jederzeit erweitert und verändert werden können - auch wenn die Ursprungsbestellung schon bezahlt wurde und nur
|
||||
noch eine Differenz gezahlt wird.
|
||||
|
||||
|
||||
Einschränkungen
|
||||
---------------
|
||||
|
||||
Zum aktuellen Zeitpunkt erlaubt die pretix-Anbindung an ePayBL nicht das durchführen von Erstattungen von bereits
|
||||
geleisteten Zahlungen. Der Prozess hierfür unterscheidet sich von Behörde zu Behörde und muss daher händisch
|
||||
durchgeführt werden.
|
||||
|
||||
.. _ePayBL: https://www.epaybl.de/
|
||||
@@ -1,105 +0,0 @@
|
||||
GetYourGuide
|
||||
============
|
||||
|
||||
.. note::
|
||||
|
||||
The GetYourGuide integration is currently in Beta. Please contact support@pretix.eu to enable the integration
|
||||
for your pretix.eu organizer account.
|
||||
|
||||
Introduction
|
||||
------------
|
||||
Using third party aggregators, such als GetYourGuide, event organizers can sell tickets to their events not only on
|
||||
their own ticket-shop but also on the aggregator's portal. While this service is not for free, it allows event
|
||||
organizers to reacher a larger audience that would otherwise not have found their way into the organizers webshop.
|
||||
|
||||
Using pretix' integration with GetYourGuide, event organizers can profit from an additional sales and revenue channel,
|
||||
while keeping the effort for setting up and maintaining multiple ticket shops to a minimum.
|
||||
|
||||
Preparing your organizer account
|
||||
--------------------------------
|
||||
The first step in enabling the GetYourGuide integration, is to setup a corresponding Sales Channel, which will be used
|
||||
to properly attribute the sales generated. This needs to be done only once per organizer account.
|
||||
|
||||
To do so, log into the pretix backend, select ``Organizers`` from the navigation and then the organizer in question.
|
||||
Extending the ``Settings``-menu, find the ``Sales channels`` configuration and click the ``Add a new channel`` button.
|
||||
|
||||
On the following page, you will be able to select ``GetYourGuide`` as the sales channel type and give it a custom name.
|
||||
|
||||
Preparing your event
|
||||
--------------------
|
||||
In order to now sell your events on GetYourGuide, you will need to configure each event in question.
|
||||
|
||||
1. Enabling the plugin
|
||||
Within your event, extend the ``Settings`` menu and navigate to ``Plugins``. Activate the plugin in the
|
||||
``Integrations`` tab.
|
||||
|
||||
2. Sell the event on the sales channel
|
||||
Pick the sales channel or channels, on which you would like to sell your event by navigating to the event's general
|
||||
settings page using the ``Sell on all sales channels`` or ``Restrict to specific sales channels`` checkboxes.
|
||||
|
||||
3. Configure one or more products to be sold on GetYourGuide
|
||||
Either create a new or edit an existing product, that you would like to sell on GetYourGuide. To do so, you will
|
||||
need to have checked the ``Sell on all sales channels`` or appropriate ``Restrict to specific sales channels``
|
||||
checkbox of the product within it's ``Availability`` tab.
|
||||
In addition, you will also need to set the GetYourGuide equivalent ticket category in the product's accordingly
|
||||
named settings tab. Within your event, there can be only one product per ticket category. Depending on your further
|
||||
configuration, you must at least select one product to be in the ``Adult`` or ``Group`` category.
|
||||
|
||||
4. Configuring the GetYourGuide-plugin
|
||||
Once you have configured one or more products to be eligible to be sold on GetYourGuide, you'll need to configure a
|
||||
few basic settings within the event (``Settings`` --> ``GetYourGuide``). The most important settings can be found
|
||||
the in the ``Configuration`` tab, such as the location of the event on sale.
|
||||
|
||||
Ticket Categories
|
||||
-----------------
|
||||
While pretix only uses the ticket category term loosely to group together multiple products for nicer display,
|
||||
GetYourGuide is relying on the ticket categories to price the tickets.
|
||||
|
||||
First of all, you need to make the decision on how you are planning on selling your tickets on GetYourGuide - in most
|
||||
cases, this will reflect your current sales strategy within your pretix shop.
|
||||
|
||||
- Individual tickets
|
||||
Every single person attending will need to purchase their own ticket. A family of two adults and two
|
||||
children will have to purchase and pay for a total of 4 tickets.
|
||||
In this case, you will need to offer *at least* a ticket of the ``Adult`` type, but may offer any other ticket
|
||||
category type (Child, Youth, Senior, ...) in addition. But you cannot offer a ``Group`` ticket.
|
||||
|
||||
- Group tickets
|
||||
Two groups, consisting of 10 and 20 participants respectively, won't need to purchase a total of 30 tickets, but
|
||||
rather two group tickets. It is up to you to configure the group size limits within the GetYourGuide-settings of your
|
||||
product.
|
||||
Choosing this option, you cannot offer any other ticket categories besides ``Group``.
|
||||
|
||||
Setting up event dates and quotas
|
||||
---------------------------------
|
||||
Of course, in addition to creating products, you will also need to add them to a quota for them to be available for
|
||||
sale. The process for doing this is the very same as for any regular event or event series.
|
||||
|
||||
.. note::
|
||||
|
||||
When selling individual tickets through GetYourGuide, you will not be able to offer differing quantities for
|
||||
individual ticket categories.
|
||||
|
||||
For this reason, we recommend to place all GetYourGuide-eligible products into the same quota. Should you however opt
|
||||
to create multiple quotas which create an imbalance, pretix will report only the available number of tickets for the
|
||||
lowest relevant quota.
|
||||
|
||||
Connecting your event to GetYourGuide
|
||||
-------------------------------------
|
||||
Once you have set up your event and products and performed all necessary configuration, you may want to use the
|
||||
Analyzer-feature of our GetYourGuide-plugin (``Settings`` -> ``GetYourGuide`` -> tab ``Analyzer``).
|
||||
|
||||
The Analyzer should not display any blocking error messages and at least one event date that is ready for publishing on
|
||||
the GetYourGuide platform.
|
||||
|
||||
At this point, you will need to setup your event (called ``product`` in the GetYourGuide universe) on their
|
||||
`Supplier Portal`_ and connect it with your pretix shop. To do so, please follow the
|
||||
`Connecting a new product to your Reservation System`_ on the GetYourGuide Supply Partner Help Center.
|
||||
|
||||
Select ``pretix.eu`` as your reservation system; the required ``product ID`` can be found in the ``Configuration`` tab
|
||||
of the GetYourGuide plugin settings page.
|
||||
|
||||
From this point on, GetYourGuide will automatically import the availabilities and products and offer them for sale.
|
||||
|
||||
.. _Supplier Portal: https://suppliers.getyourguide.com/
|
||||
.. _Connecting a new product to your Reservation System: https://supply.getyourguide.support/hc/en-us/articles/18008029689373-Connecting-a-new-product-to-your-Reservation-system
|
||||
|
Before Width: | Height: | Size: 44 KiB |
@@ -1,28 +0,0 @@
|
||||
.. _`plugin-docs`:
|
||||
|
||||
Plugin documentation
|
||||
====================
|
||||
|
||||
This part of the documentation contains information about available plugins
|
||||
that can be used to extend pretix's functionality.
|
||||
If you want to **create** a plugin, please go to the
|
||||
:ref:`Developer documentation <pluginsetup>` instead.
|
||||
|
||||
.. toctree::
|
||||
:maxdepth: 2
|
||||
|
||||
list
|
||||
banktransfer
|
||||
ticketoutputpdf
|
||||
badges
|
||||
campaigns
|
||||
certificates
|
||||
digital
|
||||
epaybl
|
||||
exhibitors
|
||||
shipping
|
||||
imported_secrets
|
||||
webinar
|
||||
presale-saml
|
||||
kulturpass
|
||||
getyourguide
|
||||
@@ -1,193 +0,0 @@
|
||||
KulturPass
|
||||
==========
|
||||
|
||||
.. note::
|
||||
|
||||
Since the KulturPass is specific to event organizers within Germany, the following page is also only provided in
|
||||
German. Should you require assistance with the KulturPass and do not speak this language, please feel free reach
|
||||
out to support@pretix.eu.
|
||||
|
||||
|
||||
Einführung
|
||||
----------
|
||||
Der `KulturPass`_ ist ein Angebot der Bundesregierung für alle, die im laufenden Jahr ihren 18. Geburtstag feiern.
|
||||
Sie erhalten ab ihrem 18. Geburtstag ein Budget von 200 Euro, das sie für Eintrittskarten, Bücher, CDs, Platten und
|
||||
vieles andere einsetzen können. So wird Kultur vor Ort noch einfacher erlebbar. Gleichzeitig stärkt das die Nachfrage
|
||||
bei den Anbietenden.
|
||||
|
||||
Da pretix ein Ticketing-System ist, stellen wir ausschließlich einen automatisierten Prozess für den Verkauf von
|
||||
Eintrittskarten über den KulturPass-Marktplatz bereit.
|
||||
|
||||
|
||||
Registrierung und Einrichtung
|
||||
-----------------------------
|
||||
Um als Unternehmen oder Kultureinrichtung Angebote auf dem KulturPass-Marktplatz anbieten zu können, ist zunächst eine
|
||||
Registerung und die Einrichtung eines "Shops" sowie der dazugehörigen Angebote notwendig.
|
||||
|
||||
1. Registrierung
|
||||
Registrieren Sie sich zunächst unter https://www.kulturpass.de/anbietende/layer als Anbieter. Im Zuge der
|
||||
Registrierung beantworten Sie einige Fragen zu Ihrem Unternehmen/Ihrer Kultureinrichtung, hinterlegen Ihre
|
||||
E-Mail-Adresse und beantworten Fragen zu Ihren Angebotsformen sowie Finanzierung Ihrer Einrichtung.
|
||||
|
||||
2. Anlegen eines KulturPass Shops
|
||||
Nach Ihrer Registrierung müssen Sie der Weitergabe Ihrer Daten an die technische Platform hinter dem KulturPass,
|
||||
Mirakl, zustimmen. Hier benennen Sie auch Ihren Shop.
|
||||
|
||||
3. Identifizierung mit ELSTER-Zertifikat
|
||||
Als nächsten Schritt müssen Sie Ihr Unternehmen oder Ihre Einrichtung mit Hilfe eines sog. ELSTER-Zertifikates
|
||||
identifizieren. Dieses Zertifikat nutzen Sie auch bereits jetzt schon, wenn Sie auf elektronischem Wege mit der
|
||||
Finanzverwaltung kommunizieren.
|
||||
|
||||
4. Ersteinrichtung in pretix
|
||||
Hinterlegen Sie nun die ID-Nummer Ihres KulturPass Marktplatz-Shops sowie einen API-Key in den
|
||||
`Einstellungen Ihres Veranstalterkontos`_ (Veranstalter-Konto -> Einstellungen -> KulturPass). Diese Daten müssen
|
||||
Sie nur einmalig für alle Ihre Veranstaltungen angeben.
|
||||
|
||||
Im `KulturPass-Backend`_ finden Sie die benötigten Informationen indem Sie auf das Benutzer-Symbol in der oberen,
|
||||
rechten Ecke klicken, "Profil" und dann "API Schlüssel" auswählen bzw. indem Sie auf "Einstellungen" in der
|
||||
Navigation links und dann "Shop" auswählen.
|
||||
|
||||
.. note::
|
||||
|
||||
Zu jedem Zeitpunkt kann nur ein Hintergrundsystem mit dem KulturPass-System verbunden sein. Werden
|
||||
unterschiedliche Systeme oder gar mehrere pretix-Veranstalterkonten mit dem gleichen KulturPass-System verbunden,
|
||||
können keine Bestellungen mehr verarbeitet werden und Angebote nicht automatisiert an den KulturPass-Marktplatz
|
||||
übermittelt werden. Eingehende Bestellungen von Jugendlichen werden in diesem Fall automatisch abgelehnt, da diese
|
||||
nicht eindeutig zugeordnet werden können. Ebenso überschreibt die Bereitstellung der Angebote eines Systems die
|
||||
Angebote eines anderen Systems.
|
||||
|
||||
Wenn Sie mehrere Systeme haben, die den KulturPass-Marktplatz bedienen sollen, wenden Sie sich bitte an den
|
||||
KulturPass-Support, um sich einen weiteren Shop einrichten zu lassen.
|
||||
|
||||
5. Aktivierung der KulturPass-Erweiterungen
|
||||
Alle Veranstaltungen, die Sie über den KulturPass anbieten möchten, benötigen die `KulturPass-Erweiterung`_.
|
||||
Aktivieren Sie diese bitte in jeder relevanten Veranstaltung über Einstellungen -> Erweiterungen -> Tab
|
||||
"Integrationen" -> KulturPass.
|
||||
|
||||
6. Konfiguration der Artikel
|
||||
Nachdem die KulturPass-Erweiterung aktiviert wurde, müssen Sie sich entscheiden, welche Produkte Sie über den
|
||||
KulturPass-Marktplatz anbieten möchten. In der Bearbeitungs-Ansicht des jeweiligen Produktes finden Sie hierzu im
|
||||
Tab "Zusätzliche Einstellungen" eine Checkbox "Das Produkt kann mit dem KulturPass erworben werden".
|
||||
|
||||
.. note::
|
||||
|
||||
Die Eigenschaft, dass ein Produkt durch den KulturPass-Marktplatz erworben werden kann, kann für beliebig viele
|
||||
Produkte aktiviert werden. Auf Grund der Funktionsweise des KulturPasses sollten Sie jedoch gerade bei vielen
|
||||
Artikeln mit unterschiedlich hohen Preisen darauf achten, dass die Preisspanne nicht zu hoch ausfällt.
|
||||
|
||||
Aktivieren Sie die Option für drei Produkte für 1, 10 und 100 Euro, so wird Ihr Angebot im KulturPass-Marktplatz
|
||||
für 100 Euro gelistet werden. Dies bedeutet im Umkehrschluss auch, dass das KulturPass-Guthaben eines Jugendlichen
|
||||
auch mindestens 100 Euro betragen muss, damit er Ihr Angebot in Anspruch nehmen kann - auch wenn die betroffene
|
||||
Person lediglich das 1 Euro-Angebot wahrnehmen möchte. Erst mit dem 100 Euro KulturPass-Einlösecode wählt die
|
||||
kaufende Person in Ihrem pretix-Shop aus, welches Produkt erworben werden soll. Ein Restguthaben wird nach dem Kauf
|
||||
automatisch zurückerstattet und dem KulturPass-Konto wieder gutgeschrieben.
|
||||
|
||||
7. Konfiguration des Marktplatz-Eintrages
|
||||
Je nach dem, ob es sich bei Ihrer Veranstaltung um eine Einzelveranstaltung oder eine Veranstaltungsreihe handelt,
|
||||
müssen Sie die folgende Einstellung einmalig oder pro Veranstaltungstermin vornehmen.
|
||||
|
||||
Einzelveranstaltungen konfigurieren Sie über den Menüpunkt "KulturPass" in den Einstellungen Ihrer Veranstaltung;
|
||||
Veranstaltungsreihen beim Anlegen oder Editieren eines jeden einzelnen Termins am Ende der Seite.
|
||||
|
||||
Um eine Veranstaltung oder einen Veranstaltungstermin im KulturPass-Marktplatz anzubieten, aktivieren Sie zunächst
|
||||
die Option "Diese Veranstaltung via KulturPass anbieten". Geben Sie im folgenden die benötigten Informationen an.
|
||||
|
||||
Bitte beachten Sie, dass Sie bei den Angaben präzise Titel und Beschreibungen verwenden, da der KulturPass-
|
||||
Marktplatz ausschließlich die Informationen aus diesem Bereich verwendet. Etwaige andere Informationen die Sie
|
||||
bspw. in den "Text auf Startseite"-Felder eingeben haben, erreichen das KulturPass-System nicht.
|
||||
|
||||
.. note::
|
||||
|
||||
Gerade bei Veranstaltungsreihen nutzen viele pretix-Veranstalter gerne verkürzte Termin-Namen. Ein Schwimmbad würde
|
||||
beispielsweise Ihre Veranstaltungsreihe "Freibad Musterstadt" und die einzelnen Termine nur "Schwimmen" nennen.
|
||||
|
||||
Während dies im pretix-Shop in einem gemeinsamen Kontext wunderbar funktioniert, würde eine Veranstaltung mit dem
|
||||
Titel "Schwimmen" im KulturPass-Marktplatz Informationen vermissen lassen. Wählen Sie daher für das Eingabefeld
|
||||
"Veranstaltungstitel" in der KulturPass-Konfiguration einen sprechenden Wert.
|
||||
|
||||
8. Übermittlung der Angebote
|
||||
Sobald Sie Ihre ersten Veranstaltungen konfiguriert und live geschaltet haben, übermittelt pretix automatisch in
|
||||
regelmäßigen Abständen alle von Ihnen angebotenen Veranstaltungen an das KulturPass System (Mirakl). Bitte beachten
|
||||
Sie jedoch, dass der Import der Produkte und Angebote einige Zeit in Anspruch nehmen kann. Zum einen müssen
|
||||
Angebote initial händisch von den Betreibern der KulturPass-Platform freigegeben werden, zum anderen muss auch eine
|
||||
Synchronisation zwischen dem Hintergrundsystem und der KulturPass-App erfolgen. Auf die Dauer dieser Prozesse hat
|
||||
pretix keinen Einfluss.
|
||||
|
||||
9. Freischalten des Marktplatz-Shops
|
||||
Nachdem pretix erstmalig Angebote an das KulturPass-System übermittelt hat, müssen Sie Ihren Shop KulturPass-Shop
|
||||
einmalig freischalten. Loggen Sie sich hierzu in das `KulturPass-Backend`_ ein.
|
||||
|
||||
|
||||
Verwalten von KulturPass-Bestellungen
|
||||
-------------------------------------
|
||||
Durch die Nutzung der pretix-Integration mit dem KulturPass-System müssen Sie sich - bis auf die Kennzeichnung von
|
||||
Produkten, die per KulturPass erworben werden dürfen, sowie die Bereitstellung von Veranstaltungs-Informationen für den
|
||||
KulturPass-Marktplatz - um nichts kümmern: pretix übermittelt automatisch Ihre Veranstaltungen, wickelt die Einlösung
|
||||
der Tickets ab und führt die Abrechnung mit dem Hintergrund-System durch.
|
||||
|
||||
Für Ihre Kunden verhält sich der KulturPass wie eine Zahlungsmethode im Bestellprozess und wird dort neben Ihren
|
||||
anderen Zahlungsmethoden mit angeboten.
|
||||
|
||||
Die Gelder für mit dem KulturPass bezahlte Tickets erhalten Sie in Form einer Sammel-Überweisung von der Stiftung
|
||||
Digitale Chancen auf das von Ihnen beim KulturPass Onboarding angegeben Bankkonto.
|
||||
|
||||
In Ihrem `KulturPass-Backend`_ können Sie über den Menüpunkt "Buchhaltung" Ihre bereits erfolgten und kommenden
|
||||
Auszahlungen betrachten.
|
||||
|
||||
.. note::
|
||||
|
||||
Es ist von äußerster Wichtigkeit, dass Sie weder die eingehenden Bestellungen noch die Produkte und Angebote im
|
||||
KulturPass-Backend händisch bearbeiten - auch wenn dies möglich wäre.
|
||||
|
||||
Bei händischen Änderungen riskieren Sie, dass die Datenbasis zwischen pretix und dem KulturPass-System divergiert
|
||||
und es zu fehlerhaften Buchungen kommt. Wann immer möglich, sollten Sie Korrekturbuchungen und Änderungen
|
||||
ausschließlich über pretix vornehmen.
|
||||
|
||||
Sollte eine händische Änderung/Korrektur notwendig werden, wenden Sie sich bitte an den pretix-Support, damit wir
|
||||
die Auswirkungen evaluieren und vorab mit Ihnen besprechen können!
|
||||
|
||||
Erstattungen für Stornos und Absagen können Sie wie gehabt über das pretix-Backend vornehmen. Der jeweilige Betrag wird
|
||||
dem KulturPass-Konto dann automatisch gutgeschrieben.
|
||||
|
||||
Da nach Ausgabe eines KulturPass Einlöse-Codes dieser vom Kunden jederzeit oder vom System bei
|
||||
Nicht-(Komplett)Einlösung binnen 48 Stunden storniert werden kann, kann das im KulturPass-Backend angezeigte,
|
||||
auszuzahlende Guthaben fluktuieren. Da in der Regel Auszahlungen frühestens 48 Stunden nach der Aufgabe einer
|
||||
KulturPass-Bestellungen erfolgen, sollte Ihr Guthaben in der Regel nicht ins Negative gehen.
|
||||
|
||||
Ablauf für Kunden
|
||||
-----------------
|
||||
Ihre Kunden erhalten - nachdem sie sich ein eigenes Konto in der KulturPass-App angelegt und sich mit ihrem
|
||||
elektronischen Personalausweis identifiziert haben - ein Guthaben von 200 Euro, welches für Leistungen aus dem
|
||||
KulturPass-Marktplatz eingelöst werden kann.
|
||||
|
||||
Im Falle von Veranstaltungen, die per pretix verkauft werden, wählt der Kunde ein Angebot aus und erhält im folgenden
|
||||
binnen kurzer Zeit (ca. 10-20 Minuten) einen Code und einen Link, um diesen einzulösen. Der Link bringt den Kunden direkt auf die Seite der
|
||||
betreffenden pretix-Veranstaltung. Hier wird der Kunde darauf hingewiesen, für welche Produkte der Code genutzt werden
|
||||
kann.
|
||||
|
||||
Im Bezahlschritt des Verkaufsprozesses wird dem Kunden vorgeschlagen, seinen KulturPass Einlösecode nun zu nutzen, um
|
||||
die gewünschte Leistung zu erhalten.
|
||||
|
||||
Wurde ein Artikel gewählt, welcher günstiger als der Wert des Einlösecodes war, wird das Restguthaben automatisch auf
|
||||
das KulturPass-Konto erstattet.
|
||||
|
||||
Wurden hingegen mehrere Artikel in den Warenkorb gelegt, so kann die Differenz mit einem anderen, regulären
|
||||
Zahlungsmittel erfolgen.
|
||||
|
||||
Einlösecodes, die vom Kunden nicht binnen 48 Stunden eingelöst werden, werden automatisch storniert und dem
|
||||
KulturPass-Konto wieder gutgeschrieben. Dieser Mechanismus greift auch, wenn eine Veranstaltung mittlerweile
|
||||
ausverkauft ist und daher der Einlösecode nicht mehr Nutzbar ist.
|
||||
|
||||
|
||||
Unterstützung
|
||||
-------------
|
||||
Weitergehende Informationen zum KulturPass finden Sie auch auf der `Webseite des KulturPasses`_, sowie im
|
||||
`KulturPass Serviceportal`_.
|
||||
|
||||
|
||||
.. _KulturPass: https://www.kulturpass.de/
|
||||
.. _Einstellungen Ihres Veranstalterkontos: https://pretix.eu/control/organizer/-/settings/kulturpass
|
||||
.. _KulturPass-Erweiterung: https://pretix.eu/control/event/-/-/settings/plugins#tab-0-2-open
|
||||
.. _KulturPass-Backend: https://kulturpass-de.mirakl.net/
|
||||
.. _Webseite des KulturPasses: https://www.kulturpass.de/
|
||||
.. _KulturPass Serviceportal: https://service.kulturpass.de/help/
|
||||
@@ -1,10 +0,0 @@
|
||||
.. spelling:word-list::
|
||||
Analytics
|
||||
|
||||
List of plugins
|
||||
===============
|
||||
|
||||
A detailed list of plugins that are available for pretix can be found on the
|
||||
`pretix Marketplace`_.
|
||||
|
||||
.. _pretix Marketplace: https://marketplace.pretix.eu
|
||||
@@ -1,405 +0,0 @@
|
||||
.. highlight:: ini
|
||||
.. spelling:word-list::
|
||||
|
||||
IdP
|
||||
skIDentity
|
||||
ePA
|
||||
NPA
|
||||
|
||||
Presale SAML Authentication
|
||||
===========================
|
||||
|
||||
The Presale SAML Authentication plugin is an advanced plugin, which most event
|
||||
organizers will not need to use. However, for the select few who do require
|
||||
strong customer authentication that cannot be covered by the built-in customer
|
||||
account functionality, this plugin allows pretix to connect to a SAML IdP and
|
||||
perform authentication and retrieval of user information.
|
||||
|
||||
Usage of the plugin is governed by two separate sets of settings: The plugin
|
||||
installation, the Service Provider (SP) configuration and the event
|
||||
configuration.
|
||||
|
||||
Plugin installation and initial configuration
|
||||
---------------------------------------------
|
||||
|
||||
.. note:: If you are a customer of our hosted `pretix.eu`_ offering, you can
|
||||
skip this section.
|
||||
|
||||
The plugin is installed as any other plugin in the pretix ecosystem. As a
|
||||
pretix system administrator, please follow the instructions in the the
|
||||
:ref:`Administrator documentation <admindocs>`.
|
||||
|
||||
Once installed, you will need to assess, if you want (or need) your pretix
|
||||
instance to be a single SP for all organizers and events or if every event
|
||||
organizer has to provide their own SP.
|
||||
|
||||
Take the example of a university which runs pretix under an pretix Enterprise
|
||||
agreement. Since they only provide ticketing services to themselves (every
|
||||
organizer is still just a different department of the same university), a
|
||||
single SP should be enough.
|
||||
|
||||
On the other hand, a reseller such as `pretix.eu`_ who services a multitude
|
||||
of clients would not work that way. Here, every organizer is a separate
|
||||
legal entity and as such will also need to provide their own SP configuration:
|
||||
Company A will expect their SP to reflect their company - and not a generalized
|
||||
"pretix SP".
|
||||
|
||||
Once you have decided on the mode of operation, the :ref:`Configuration file
|
||||
<config>` needs to be extended to reflect your choice.
|
||||
|
||||
Example::
|
||||
|
||||
[presale-saml]
|
||||
level=global
|
||||
|
||||
``level``
|
||||
``global`` to use only a single, system-wide SP, ``organizer`` for multiple
|
||||
SPs, configured on the organizer-level. Defaults to ``organizer``.
|
||||
|
||||
Service Provider configuration
|
||||
------------------------------
|
||||
|
||||
Global Level
|
||||
^^^^^^^^^^^^
|
||||
|
||||
.. note:: If you are a customer of our hosted `pretix.eu`_ offering, you can
|
||||
skip this section and follow the instructions on the upcoming
|
||||
Organizer Level settings.
|
||||
|
||||
As a user with administrative privileges, please activate them by clicking the
|
||||
`Admin Mode` button in the top right hand corner.
|
||||
|
||||
You should now see a new menu-item titled `SAML` appear.
|
||||
|
||||
Organizer Level
|
||||
^^^^^^^^^^^^^^^
|
||||
|
||||
Navigate to the organizer settings in the pretix backend. In the navigation
|
||||
bar, you will find a menu-item titled `SAML` if your user has the `Can
|
||||
change organizer settings` permission.
|
||||
|
||||
|
||||
.. note:: If you are a customer of our hosted `pretix.eu`_ offering, the menu
|
||||
will only appear once one of our friendly customer service agents
|
||||
has enabled the Presale SAML Authentication plugin for at least one
|
||||
of your events. Feel free to get in touch with us!
|
||||
|
||||
Setting up the SP
|
||||
^^^^^^^^^^^^^^^^^
|
||||
|
||||
No matter where your SP configuration lives, you will be greeted by a very
|
||||
long list of fields of which almost all of them will need to be filled. Please
|
||||
don't be discouraged - most of the settings don't need to be decided by yourself
|
||||
and/or are already preset with a sensible default setting.
|
||||
|
||||
If you are not sure what setting you should choose for any of the fields, you
|
||||
should reach out to your IdP operator as they can tell you exactly what the IdP
|
||||
expects and - more importantly - supports.
|
||||
|
||||
``IdP Metadata URL``
|
||||
Please provide the URL where your IdP outputs its metadata. For most IdPs,
|
||||
this URL is static and the same for all SPs. If you are a member of the
|
||||
DFN-AAI, you can find the meta-data for the `Test-, Basic- and
|
||||
Advanced-Federation`_ on their website. Please do talk with your local
|
||||
IdP operator though, as you might not even need to go through the DFN-AAI
|
||||
and might just use your institutions local IdP which will also host their
|
||||
metadata on a different URL.
|
||||
|
||||
The URL needs to be publicly accessible, as saving the settings form will
|
||||
fail if the IdP metadata cannot be retrieved. pretix will also automatically
|
||||
refresh the IdP metadata on a regular basis.
|
||||
|
||||
``SP Entity Id``
|
||||
By default, we recommend that you use the system-proposed metadata-URL as
|
||||
the Entity Id of your SP. However, if so desired or required by your IdP,
|
||||
you can also set any other, arbitrary URL as the SP Entity Id.
|
||||
|
||||
``SP Name / SP Decription``
|
||||
Most IdP will display the name and description of your SP to the users
|
||||
during authentication. The description field can be used to explain to the
|
||||
users how their data is being used.
|
||||
|
||||
``SP X.509 Certificate / SP X.509 Private Key``
|
||||
Your SP needs a certificate and a private key for said certificate. Please
|
||||
coordinate with your IdP, if you are supposed to generate these yourself or
|
||||
if they are provided to you.
|
||||
|
||||
``SP X.509 New Certificate``
|
||||
As certificates have an expiry date, they need to be renewed on a regular
|
||||
basis. In order to facilitate the rollover from the expiring to the new
|
||||
certificate, you can provide the new certificate already before the expiration
|
||||
of the existing one. That way, the system will automatically use the correct
|
||||
one. Once the old certificate has expired and is not used anymore at all,
|
||||
you can move the new certificate into the slot of the normal certificate and
|
||||
keep the new slot empty for your next renewal process.
|
||||
|
||||
``Requested Attributes``
|
||||
An IdP can hold a variety of attributes of an authenticating user. While
|
||||
your IdP will dictate which of the available attributes your SP can consume
|
||||
in theory, you will still need to define exactly which attributes the SP
|
||||
should request.
|
||||
|
||||
The notation is a JSON list of objects with 5 attributes each:
|
||||
|
||||
* ``attributeValue``: Can be defaulted to ``[]``.
|
||||
* ``friendlyName``: String used in the upcoming event-level settings to
|
||||
retrieve the attributes data.
|
||||
* ``isRequired``: Boolean indicating whether the IdP must enforce the
|
||||
transmission of this attribute. In most cases, ``true`` is the best
|
||||
choice.
|
||||
* ``name``: String of the internal, technical name of the requested
|
||||
attribute. Often starting with ``urn:mace:dir:attribute-def:``,
|
||||
``urn:oid:`` or ``http://``/``https://``.
|
||||
* ``nameFormat``: String describing the type of ``name`` that has been
|
||||
set in the previous section. Often starting with
|
||||
``urn:mace:shibboleth:1.0:`` or ``urn:oasis:names:tc:SAML:2.0:``.
|
||||
|
||||
Your IdP can provide you with a list of available attributes. See below
|
||||
for a sample configuration in an academic context.
|
||||
|
||||
Note, that you can have multiple attributes with the same ``friendlyName``
|
||||
but different ``name`` value. This is often used in systems, where the same
|
||||
information (for example a persons name) is saved in different fields -
|
||||
for example because one institution is returning SAML 1.0 and other
|
||||
institutions are returning SAML 2.0 style attributes. Typically, this only
|
||||
occurs in mix environments like the DFN-AAI with a large number of
|
||||
participants. If you are only using your own institutions IdP and not
|
||||
authenticating anyone outside of your realm, this should not be a common
|
||||
sight.
|
||||
|
||||
``Encrypt/Sign/Require ...``
|
||||
Does what is says on the box - please inquire with your IdP for the
|
||||
necessary settings. Most settings can be turned on as they increase security,
|
||||
however some IdPs might stumble over some of them.
|
||||
|
||||
``Signature / Digest Algorithm``
|
||||
Please chose appropriate algorithms, that both pretix/your SP and the IdP
|
||||
can communicate with. A common source of issues when connecting to a
|
||||
Shibboleth-based IdP is the Digest Algorithm: pretix does not support
|
||||
``http://www.w3.org/2009/xmlenc11#rsa-oaep`` and authentication will fail
|
||||
if the IdP enforces this.
|
||||
|
||||
``Technical/Support Contacts``
|
||||
Those contacts are encoded into the SPs public meta data and might be
|
||||
displayed to users having trouble authenticating. It is recommended to
|
||||
provide a dedicated point of contact for technical issues, as those will
|
||||
be the ones to change the configuration for the SP.
|
||||
|
||||
Event / Authentication configuration
|
||||
------------------------------------
|
||||
|
||||
Basic settings
|
||||
^^^^^^^^^^^^^^
|
||||
|
||||
Once the plugin has been enabled for a pretix event using the Plugins-menu from
|
||||
the event's settings, a new *SAML* menu item will show up.
|
||||
|
||||
On this page, the actual authentication can be configured.
|
||||
|
||||
``Checkout Explanation``
|
||||
Since most users probably won't be familiar with why they have to authenticate
|
||||
to buy a ticket, you can provide them a small blurb here. Markdown is supported.
|
||||
|
||||
``Attribute RegEx``
|
||||
By default, any successful authentication with the IdP will allow the user to
|
||||
proceed with their purchase. Should the allowed audience needed to be restricted
|
||||
further, a set of regular Expressions can be used to do this.
|
||||
|
||||
An Attribute RegEx of ``{}`` will allow any authenticated user to pass.
|
||||
|
||||
A RegEx of ``{ "affiliation": "^(employee@pretix.eu|staff@pretix.eu)$" }`` will
|
||||
only allow user to pass which have the ``affiliation`` attribute and whose
|
||||
attribute either matches ``employee@pretix.eu`` or ``staff@pretix.eu``.
|
||||
|
||||
Please make sure that the attribute you are querying is also requested from the
|
||||
IdP in the first place - for a quick check you can have a look at the top of
|
||||
the page where all currently configured attributes are listed.
|
||||
|
||||
``RegEx Fail Explanation``
|
||||
Only used in conjunction with the above Attribute RegEx. Should the user not
|
||||
pass the restrictions imposed by the regular expression, the user is shown
|
||||
this error-message.
|
||||
|
||||
If you are - for example in an university context - restricting access to
|
||||
students only, you might want to explain here that Employees are not allowed
|
||||
to book tickets.
|
||||
|
||||
``Ticket Secret SAML Attribute``
|
||||
In very specific instances, it might be desirable that the ticket-secret is
|
||||
not the randomly one generated by pretix but rather based on one of the
|
||||
users attributes - for example their unique ID or access card number.
|
||||
|
||||
To achieve this, the name of a SAML-attribute can be specified here.
|
||||
|
||||
It is however necessary to note, that even with this setting in use,
|
||||
ticket-secrets need to be unique. This is why when this setting is enabled,
|
||||
the default, pretix-generated ticket-secret is prefixed with the attributes
|
||||
value.
|
||||
|
||||
Example: A users ``cardid`` attribute has the value of ``01189998819991197253``.
|
||||
The default random ticket secret would have been
|
||||
``yczygpw9877akz2xwdhtdyvdqwkv7npj``. The resulting new secret will now be
|
||||
``01189998819991197253_yczygpw9877akz2xwdhtdyvdqwkv7npj``.
|
||||
|
||||
That way, the ticket secret is still unique, but when checking into an event,
|
||||
the user can easily be searched and found using their identifier.
|
||||
|
||||
IdP-provided E-Mail addresses, names
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
By default, pretix will only authenticate the user and not process the received
|
||||
data any further.
|
||||
|
||||
However, there are a few exceptions to this rule.
|
||||
|
||||
There are a few `magic` attributes that pretix will use to automatically populate
|
||||
the corresponding fields within the checkout process **and lock them out from
|
||||
user editing**.
|
||||
|
||||
* ``givenName`` and ``sn``: If both of those attributes are present and pretix
|
||||
is configured to collect the users name, these attributes' values are used
|
||||
for the given and family name respectively.
|
||||
* ``email``: If this attribute is present, the E-Mail-address of the users will
|
||||
be set to the one transmitted through the attributes.
|
||||
|
||||
The latter might pose a problem, if the IdP is transmitting an ``email`` attribute
|
||||
which does contain a system-level mail address which is only used as an internal
|
||||
identifier but not as a real mailbox. In this case, please consider setting the
|
||||
``friendlyName`` of the attribute to a different value than ``email`` or removing
|
||||
this field from the list of requested attributes altogether.
|
||||
|
||||
Saving attributes to questions
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
By setting the ``internal identifier`` of a user-defined question to the same name
|
||||
as a SAML attribute, pretix will save the value of said attribute into the question.
|
||||
|
||||
All the same as in the above section on E-Mail addresses, those fields become
|
||||
non-editable by the user.
|
||||
|
||||
Please be aware that some specialty question types might not be compatible with
|
||||
the SAML attributes due to specific format requirements. If in doubt (or if the
|
||||
checkout fails/the information is not properly saved), try setting the question
|
||||
type to a simple type like "Text (one line)".
|
||||
|
||||
Notes and configuration examples
|
||||
--------------------------------
|
||||
|
||||
Requesting SAML 1.0 and 2.0 attributes from an academic IdP
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
This requests the ``eduPersonPrincipalName`` (also sometimes called EPPN),
|
||||
``email``, ``givenName`` and ``sn`` both in SAML 1.0 and SAML 2.0 attributes.
|
||||
|
||||
.. sourcecode:: json
|
||||
|
||||
[
|
||||
{
|
||||
"attributeValue": [],
|
||||
"friendlyName": "eduPersonPrincipalName",
|
||||
"isRequired": true,
|
||||
"name": "urn:mace:dir:attribute-def:eduPersonPrincipalName",
|
||||
"nameFormat": "urn:mace:shibboleth:1.0:attributeNamespace:uri"
|
||||
},
|
||||
{
|
||||
"attributeValue": [],
|
||||
"friendlyName": "eduPersonPrincipalName",
|
||||
"isRequired": true,
|
||||
"name": "urn:oid:1.3.6.1.4.1.5923.1.1.1.6",
|
||||
"nameFormat": "urn:oasis:names:tc:SAML:2.0:attrname-format:uri"
|
||||
},
|
||||
{
|
||||
"attributeValue": [],
|
||||
"friendlyName": "email",
|
||||
"isRequired": true,
|
||||
"name": "urn:mace:dir:attribute-def:mail",
|
||||
"nameFormat": "urn:mace:shibboleth:1.0:attributeNamespace:uri"
|
||||
},
|
||||
{
|
||||
"attributeValue": [],
|
||||
"friendlyName": "email",
|
||||
"isRequired": true,
|
||||
"name": "urn:oid:0.9.2342.19200300.100.1.3",
|
||||
"nameFormat": "urn:oasis:names:tc:SAML:2.0:attrname-format:uri"
|
||||
},
|
||||
{
|
||||
"attributeValue": [],
|
||||
"friendlyName": "givenName",
|
||||
"isRequired": true,
|
||||
"name": "urn:mace:dir:attribute-def:givenName",
|
||||
"nameFormat": "urn:mace:shibboleth:1.0:attributeNamespace:uri"
|
||||
},
|
||||
{
|
||||
"attributeValue": [],
|
||||
"friendlyName": "givenName",
|
||||
"isRequired": true,
|
||||
"name": "urn:oid:2.5.4.42",
|
||||
"nameFormat": "urn:oasis:names:tc:SAML:2.0:attrname-format:uri"
|
||||
},
|
||||
{
|
||||
"attributeValue": [],
|
||||
"friendlyName": "sn",
|
||||
"isRequired": true,
|
||||
"name": "urn:mace:dir:attribute-def:sn",
|
||||
"nameFormat": "urn:mace:shibboleth:1.0:attributeNamespace:uri"
|
||||
},
|
||||
{
|
||||
"attributeValue": [],
|
||||
"friendlyName": "sn",
|
||||
"isRequired": true,
|
||||
"name": "urn:oid:2.5.4.4",
|
||||
"nameFormat": "urn:oasis:names:tc:SAML:2.0:attrname-format:uri"
|
||||
}
|
||||
]
|
||||
|
||||
skIDentity IdP Metadata URL
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
Since the IdP Metadata URL for `skIDentity`_ is not readily documented/visible
|
||||
in their backend, we document it here:
|
||||
``https://service.skidentity.de/fs/saml/metadata``
|
||||
|
||||
Requesting skIDentity attributes for electronic identity cards
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
This requests the basic ``eIdentifier``, ``IDType``, ``IDIssuer``, and
|
||||
``NameID`` from the `skIDentity`_ SAML service, which are available for
|
||||
electronic ID cards such as the German ePA/NPA. (Other attributes such as
|
||||
the name and address are available at additional cost from the IdP).
|
||||
|
||||
.. sourcecode:: json
|
||||
|
||||
[
|
||||
{
|
||||
"attributeValue": [],
|
||||
"friendlyName": "eIdentifier",
|
||||
"isRequired": true,
|
||||
"name": "http://www.skidentity.de/att/eIdentifier",
|
||||
"nameFormat": "urn:oasis:names:tc:SAML:2.0:attrname-format:uri"
|
||||
},
|
||||
{
|
||||
"attributeValue": [],
|
||||
"friendlyName": "IDType",
|
||||
"isRequired": true,
|
||||
"name": "http://www.skidentity.de/att/IDType",
|
||||
"nameFormat": "urn:oasis:names:tc:SAML:2.0:attrname-format:uri"
|
||||
},
|
||||
{
|
||||
"attributeValue": [],
|
||||
"friendlyName": "IDIssuer",
|
||||
"isRequired": true,
|
||||
"name": "http://www.skidentity.de/att/IDIssuer",
|
||||
"nameFormat": "urn:oasis:names:tc:SAML:2.0:attrname-format:uri"
|
||||
},
|
||||
{
|
||||
"attributeValue": [],
|
||||
"friendlyName": "NameID",
|
||||
"isRequired": true,
|
||||
"name": "http://www.skidentity.de/att/NameID",
|
||||
"nameFormat": "urn:oasis:names:tc:SAML:2.0:attrname-format:uri"
|
||||
}
|
||||
]
|
||||
|
||||
.. _pretix.eu: https://pretix.eu
|
||||
.. _Test-, Basic- and Advanced-Federation: https://doku.tid.dfn.de/en:metadata
|
||||
.. _skIDentity: https://www.skidentity.de/
|
||||
@@ -1,43 +0,0 @@
|
||||
pretix Webinar
|
||||
==============
|
||||
|
||||
Fetch host URLs
|
||||
---------------
|
||||
|
||||
.. http:get:: /api/v1/organizers/(organizer)/events/(event)/webinars/
|
||||
|
||||
Returns a list of all currently available webinar calls configured for an event.
|
||||
|
||||
**Example request**:
|
||||
|
||||
.. sourcecode:: http
|
||||
|
||||
GET /api/v1/organizers/bigevents/events/sampleconf/webinars/ HTTP/1.1
|
||||
Host: pretix.eu
|
||||
Accept: application/json, text/javascript
|
||||
|
||||
**Example response**:
|
||||
|
||||
.. sourcecode:: http
|
||||
|
||||
HTTP/1.1 200 OK
|
||||
Vary: Accept
|
||||
Content-Type: application/json
|
||||
|
||||
[
|
||||
{
|
||||
"name": "Webinar B – Sept. 8th, 2020",
|
||||
"hosturl": "http://pretix.eu/demo/museum/webinar/host/a9aded3d7bd4df60/30611a34f9fee5d3/"
|
||||
},
|
||||
{
|
||||
"name": "Webinar A – Sept. 8, 2020",
|
||||
"hosturl": "http://pretix.eu/demo/museum/webinar/host/e714x7d4a4a36a04/b9cc444665xxx757/"
|
||||
}
|
||||
]
|
||||
|
||||
:query subevent: Limit the result to the webinar(s) for a specific subevent.
|
||||
:param organizer: The ``slug`` field of a valid organizer
|
||||
:param event: The ``slug`` field of the event to fetch
|
||||
:statuscode 200: no error
|
||||
:statuscode 401: Authentication failure
|
||||
:statuscode 403: The requested organizer or event does not exist **or** you have no permission to view it.
|
||||
|
Before Width: | Height: | Size: 89 KiB |
|
Before Width: | Height: | Size: 88 KiB |
|
Before Width: | Height: | Size: 56 KiB |
|
Before Width: | Height: | Size: 103 KiB |
|
Before Width: | Height: | Size: 26 KiB |
|
Before Width: | Height: | Size: 130 KiB |
|
Before Width: | Height: | Size: 92 KiB |
|
Before Width: | Height: | Size: 30 KiB |
|
Before Width: | Height: | Size: 83 KiB |
|
Before Width: | Height: | Size: 141 KiB |
|
Before Width: | Height: | Size: 93 KiB |
|
Before Width: | Height: | Size: 106 KiB |
|
Before Width: | Height: | Size: 118 KiB |
|
Before Width: | Height: | Size: 109 KiB |
|
Before Width: | Height: | Size: 103 KiB |
|
Before Width: | Height: | Size: 71 KiB |
|
Before Width: | Height: | Size: 72 KiB |
|
Before Width: | Height: | Size: 70 KiB |
|
Before Width: | Height: | Size: 98 KiB |
|
Before Width: | Height: | Size: 61 KiB |
|
Before Width: | Height: | Size: 53 KiB |
|
Before Width: | Height: | Size: 88 KiB |
|
Before Width: | Height: | Size: 116 KiB |
|
Before Width: | Height: | Size: 74 KiB |
|
Before Width: | Height: | Size: 47 KiB |
|
Before Width: | Height: | Size: 53 KiB |
|
Before Width: | Height: | Size: 94 KiB |
|
Before Width: | Height: | Size: 114 KiB |
|
Before Width: | Height: | Size: 96 KiB |
|
Before Width: | Height: | Size: 69 KiB |
|
Before Width: | Height: | Size: 76 KiB |
|
Before Width: | Height: | Size: 87 KiB |
|
Before Width: | Height: | Size: 104 KiB |
|
Before Width: | Height: | Size: 86 KiB |
|
Before Width: | Height: | Size: 98 KiB |
|
Before Width: | Height: | Size: 98 KiB |
|
Before Width: | Height: | Size: 64 KiB |
|
Before Width: | Height: | Size: 47 KiB |
|
Before Width: | Height: | Size: 65 KiB |
|
Before Width: | Height: | Size: 78 KiB |
|
Before Width: | Height: | Size: 49 KiB |
@@ -1,210 +0,0 @@
|
||||
.. _customers:
|
||||
|
||||
Customer accounts
|
||||
=================
|
||||
|
||||
By default, pretix only offers guest checkout, i.e. ticket buyers do not sign up and sign back in, but create a new
|
||||
checkout session every time. In some situations it may be convenient to allow ticket buyers to create
|
||||
accounts that they can later log in to again. Working with customer accounts is even required for some advanced
|
||||
use cases such as described in the :ref:`seasontickets` article.
|
||||
|
||||
Enabling customer accounts
|
||||
--------------------------
|
||||
|
||||
To enable customer accounts, head to your organizer page in the backend and then select "Settings" → "General" →
|
||||
"Customer accounts" and turn on the checkbox "Allow customers to create accounts".
|
||||
|
||||
Using the other settings on the same tab you can fine-tune how the customer account system behaves:
|
||||
|
||||
.. thumbnail:: ../../screens/organizer/edit_customer.png
|
||||
:align: center
|
||||
:class: screenshot
|
||||
|
||||
Allow customers to log in with email address and password
|
||||
In all simple setups, this option should be checked. If this checkbox is removed, it is impossible to log in or
|
||||
sign up unless you connect a SSO provider (see below).
|
||||
|
||||
Match orders based on email address
|
||||
If this option is selected, customers will see orders made with their email address within their account even if
|
||||
they did not make those orders while logged in.
|
||||
|
||||
Name format, Allowed titles
|
||||
This controls how we'll ask your customers for their name, similar to the respective settings on event level.
|
||||
|
||||
Managing customer accounts
|
||||
--------------------------
|
||||
|
||||
After customer accounts have been enabled, you will find a new menu option "Customer accounts" in the organizer-level
|
||||
main menu. The first sub-item, "Customers", allows you to search and inspect the list of your customer accounts, as well
|
||||
as to create a new customer account from the backend:
|
||||
|
||||
.. thumbnail:: ../../screens/organizer/customers.png
|
||||
:align: center
|
||||
:class: screenshot
|
||||
|
||||
If you click on a customer ID, you can see all details of this customer account, including registration information,
|
||||
active memberships, past ticket orders, and account history:
|
||||
|
||||
.. thumbnail:: ../../screens/organizer/customer.png
|
||||
:align: center
|
||||
:class: screenshot
|
||||
|
||||
You can also perform various actions from this view, such as:
|
||||
|
||||
- Send a password reset link
|
||||
- Change registration information
|
||||
- Anonymize the customer account (does not anonymize connected orders)
|
||||
|
||||
When creating or changing a customer, you will be presented with the following form:
|
||||
|
||||
.. thumbnail:: ../../screens/organizer/customer_edit.png
|
||||
:align: center
|
||||
:class: screenshot
|
||||
|
||||
Most fields, such as name, e-mail address, phone number, and language should be self-explanatory. The following fields
|
||||
might require some explanation:
|
||||
|
||||
Account active
|
||||
If this checkbox is removed, the customer will not be able to log in.
|
||||
|
||||
External identifier
|
||||
This field can be used to cross-reference your customer database with other sources. For example, if the customer
|
||||
already has a number in another system, you can insert that number here. This can be especially powerful if you
|
||||
use our API for synchronization with an external system.
|
||||
|
||||
Verified email address
|
||||
This checkbox signifies whether you have verified that this customer in fact controls the given email address.
|
||||
This will automatically be checked after a successful registration or after a successful password reset. Before it
|
||||
is checked, the customer will not be able to log in. You should usually not modify this field manually.
|
||||
|
||||
Notes
|
||||
Entries in this field will only be visible to you and your team, not to the customer.
|
||||
|
||||
Single-Sign-On (SSO)
|
||||
--------------------
|
||||
|
||||
"Single-Sign-On" (SSO) is a technical term for a situation in which a person can log in to multiple systems using just
|
||||
one login. This can be convenient if you have multiple applications that are exposed to your customers: They won't have
|
||||
to remember multiple passwords or understand how your application landscape is structured, they can just always log in
|
||||
with the same credentials whenever they see your brand.
|
||||
|
||||
In this scenario, pretix can be **either** the "SSO provider" **or** the "SSO client".
|
||||
If pretix is the SSO provider, pretix will be the central source of truth for your customer accounts and your other
|
||||
applications can connect to pretix to use pretix's login functionality.
|
||||
If pretix is the SSO client, one of your existing systems will be the source of truth for the customer accounts and
|
||||
pretix will use that system's login functionality.
|
||||
|
||||
All SSO support for customer accounts in pretix is currently built on the `OpenID Connect`_ standard, a modern and
|
||||
widely accepted standard for SSO in all industries.
|
||||
|
||||
Connecting SSO clients (pretix as the SSO provider)
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
To connect an external application as a SSO client, go to "Customer accounts" → "SSO clients" → "Create a new SSO client"
|
||||
in your organizer account.
|
||||
|
||||
.. thumbnail:: ../../screens/organizer/customer_ssoclient_add.png
|
||||
:align: center
|
||||
:class: screenshot
|
||||
|
||||
You will need to fill out the following fields:
|
||||
|
||||
Active
|
||||
If this checkbox is removed, the SSO client can not be used.
|
||||
|
||||
Application name
|
||||
The name of your external application, e.g. "digital event marketplace".
|
||||
|
||||
Client type
|
||||
For a server-side application which is able to store a secret that will be inaccessible to end users, chose
|
||||
"confidential". For a client-side application, such as many mobile apps, choose "public".
|
||||
|
||||
Grant type
|
||||
This value depends on the OpenID Connect implementation of your software.
|
||||
|
||||
Redirection URIs
|
||||
One or multiple URIs that the user might be redirected to after the successful or failed login.
|
||||
|
||||
Allowed access scopes
|
||||
The types of data the SSO client may access about the customer.
|
||||
|
||||
After you submitted all data, you will receive a client ID as well as a client secret. The client secret is shown
|
||||
in the green success message and will only ever be shown once. If you need it again, use the option "Invalidate old
|
||||
client secret and generate a new one".
|
||||
|
||||
You will need the client ID and client secret to configure your external application. The application will also likely
|
||||
need some other information from you, such as your **issuer URI**. If you use pretix Hosted and your organizer account
|
||||
does not have a custom domain, your issuer will be ``https://pretix.eu/myorgname``, where ``myorgname`` is the short
|
||||
form of your organizer account. If you use a custom domain, such as ``tickets.mycompany.net``, then your issuer will be
|
||||
``https://tickets.mycompany.net``.
|
||||
|
||||
Technical details
|
||||
"""""""""""""""""
|
||||
|
||||
We implement `OpenID Connect Core 1.0`_, except for some optional parts that do not make sense for pretix or bring no
|
||||
additional value. For example, we do not currently support encrypted tokens, offline access, refresh tokens, or passing
|
||||
request parameters as JWTs.
|
||||
|
||||
We implement the provider metadata section from `OpenID Connect Discovery 1.0`_. You can find the endpoint relative
|
||||
to the issuer URI as described above, for example ``http://pretix.eu/demo/.well-known/openid-configuration``.
|
||||
|
||||
We implement all three OpenID Connect Core flows:
|
||||
|
||||
- Authorization Code Flow (response type ``code``)
|
||||
- Implicit Flow (response types ``id_token token`` and ``id_token``)
|
||||
- Hybrid Flow (response types ``code id_token``, ``code id_token token``, and ``code token``)
|
||||
|
||||
We implement the response modes ``query`` and ``fragment``.
|
||||
|
||||
We currently offer the following scopes: ``openid``, ``profile``, ``email``, ``phone``
|
||||
|
||||
As well as the following standardized claims: ``iss``, ``aud``, ``exp``, ``iat``, ``auth_time``, ``nonce``, ``c_hash``,
|
||||
``at_hash``, ``sub``, ``locale``, ``name``, ``given_name``, ``family_name``, ``middle_name``, ``nickname``, ``email``,
|
||||
``email_verified``, ``phone_number``.
|
||||
|
||||
The various endpoints are located relative to the issuer URI as described above:
|
||||
|
||||
- Authorization: ``<issuer>/oauth2/v1/authorize``
|
||||
- Token: ``<issuer>/oauth2/v1/token``
|
||||
- User info: ``<issuer>/oauth2/v1/userinfo``
|
||||
- Keys: ``<issuer>/oauth2/v1/keys``
|
||||
|
||||
We currently do not reproduce their documentation here as they follow the OpenID Connect and OAuth specifications
|
||||
without any special behavior.
|
||||
|
||||
Connecting SSO providers (pretix as the SSO client)
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
To connect an external application as a SSO provider, go to "Customer accounts" → "SSO providers" → "Create a new SSO provider"
|
||||
in your organizer account.
|
||||
|
||||
.. thumbnail:: ../../screens/organizer/customer_ssoprovider_add.png
|
||||
:align: center
|
||||
:class: screenshot
|
||||
|
||||
The "Provider name" and "Login button label" is what we'll use to show the new login option to the user. For the actual
|
||||
connection, we will require information such as the issuer URL, client ID, client secret, scope, and field (or claim)
|
||||
names that you will receive from your SSO provider.
|
||||
|
||||
.. note::
|
||||
|
||||
If you want your customers to *only* use your SSO provider, it makes sense to turn off the "Allow customers to log in
|
||||
with email address and password" settings option (see above).
|
||||
|
||||
Technical details
|
||||
"""""""""""""""""
|
||||
|
||||
We assume that SSO providers fulfill the following requirements:
|
||||
|
||||
- Implementation according to `OpenID Connect Core 1.0`_.
|
||||
|
||||
- Published meta-data document at ``<issuer>/.well-known/openid-configuration`` as specified in `OpenID Connect Discovery 1.0`_.
|
||||
|
||||
- Support for Authorization code flow (``response_type=code``) with ``response_mode=query``.
|
||||
|
||||
- Support for client authentication using client ID and client secret and without public key cryptography.
|
||||
|
||||
|
||||
.. _OpenID Connect: https://en.wikipedia.org/wiki/OpenID#OpenID_Connect_(OIDC)
|
||||
.. _OpenID Connect Core 1.0: https://openid.net/specs/openid-connect-core-1_0.html
|
||||
.. _OpenID Connect Discovery 1.0: https://openid.net/specs/openid-connect-discovery-1_0.html
|
||||
@@ -1,99 +0,0 @@
|
||||
.. _event_create:
|
||||
|
||||
Creating an event
|
||||
=================
|
||||
|
||||
After you have created an organizer account, the next step is to create your event. An event is the basic object in
|
||||
pretix that everything is organized around. One event corresponds to one ticket shop with all its products, quotas,
|
||||
orders and settings.
|
||||
|
||||
To create an event, you can click the "Create a new event" tile on your dashboard or the button above the list of
|
||||
events. You will then be presented with the first step of event creation:
|
||||
|
||||
.. thumbnail:: ../../screens/event/create_step1.png
|
||||
:align: center
|
||||
:class: screenshot
|
||||
|
||||
Here, you first need to decide for the organizer the event belongs to. You will not be able to change this
|
||||
association later. This will determine default settings for the event, as well as access control to the event's
|
||||
settings.
|
||||
|
||||
Second, you need to select the languages that the ticket shop should be available in. You can change this setting
|
||||
later, but if you select it correctly now, it will automatically ask you for all descriptions in the respective
|
||||
languages starting from the next step.
|
||||
|
||||
Last on this page, you can decide if this event represents an event series. In this cases, the event will turn into
|
||||
multiple events included in once, meaning that you will get one combined ticket shop for multiple actual events. This
|
||||
is useful if you have a large number of events that are very similar to each other and that should be sold together
|
||||
(i.e. users should be able to buy tickets for multiple events at the same time). Those single events can differ in
|
||||
available products, quotas, prices and some meta information, but most settings need to be the same for all of them.
|
||||
We recommend to use this feature only if you really know that you need it and if you really run a lot of events, not if
|
||||
you run e.g. a yearly conference. You can read more on this feature :ref:`here <subevents>`.
|
||||
|
||||
Once you set these values, you can proceed to the next step:
|
||||
|
||||
.. thumbnail:: ../../screens/event/create_step2.png
|
||||
:align: center
|
||||
:class: screenshot
|
||||
|
||||
In this step, you will be asked more detailed questions about your event. In particular, you can fill in the
|
||||
following fields:
|
||||
|
||||
Name
|
||||
This is the public name of your event. It should be descriptive and tell both you and the user which event you are
|
||||
dealing with, but should still be concise. You probably know how your event is named already ;)
|
||||
|
||||
Short form
|
||||
This will be used in multiple places. For example, the URL of your ticket shop will include this short form of
|
||||
your event name, but it will also be the default prefix e.g. for invoice numbers. We recommend to use some natural
|
||||
abbreviation of your event name, maybe together with a date, of no more than 10 characters. This is the only value
|
||||
on this page that can't be changed later.
|
||||
|
||||
Event start time
|
||||
The date and time that your event starts at. You can later configure settings to hide the time, if you don't want
|
||||
to show that.
|
||||
|
||||
Event end time
|
||||
The date and time your event ends at. You can later configure settings to hide this value completely -- or you can
|
||||
just leave it empty. It's optional!
|
||||
|
||||
Location
|
||||
This is the location of your event in a human-readable format. We will show this on the ticket shop frontpage, but
|
||||
it might also be used e.g. in Wallet tickets.
|
||||
|
||||
Event currency
|
||||
This is the currency all prices and payments in your shop will be handled in.
|
||||
|
||||
Sales tax rate
|
||||
If you need to pay a form of sales tax (also known as VAT in many countries) on your products, you can set a tax rate
|
||||
in percent here that will be used as a default later. After creating your event, you can also create multiple tax
|
||||
rates or fine-tune the tax settings.
|
||||
|
||||
Default language
|
||||
If you selected multiple supported languages in the previous step, you can now decide which one should be
|
||||
displayed by default.
|
||||
|
||||
Start of presale
|
||||
If you set this date, no ticket will be sold before this date. We normally recommend not to set this date during
|
||||
event creation because it will make testing your shop harder.
|
||||
|
||||
End of presale
|
||||
If you set this date, no ticket will be sold after this date.
|
||||
|
||||
If all of this is set, you can proceed to the next step. If this is your first event, there will not be a next step
|
||||
and you are done! If you have already created events before, you will be asked if you want to copy settings from one
|
||||
of them:
|
||||
|
||||
.. thumbnail:: ../../screens/event/create_step3.png
|
||||
:align: center
|
||||
:class: screenshot
|
||||
|
||||
If you do so, all products, categories, quotas and most settings of the other event will be taken over. You should
|
||||
still review them if they make sense for your new event, but it could save you a lot of work. After this step, your
|
||||
event is created successfully:
|
||||
|
||||
.. thumbnail:: ../../screens/event/create_step4.png
|
||||
:align: center
|
||||
:class: screenshot
|
||||
|
||||
You can now fine-tune all settings to your liking, publish your event and start selling tickets!
|
||||
@@ -1,55 +0,0 @@
|
||||
Display settings
|
||||
================
|
||||
|
||||
The settings at "Settings" → "Display" allow you to customize the appearance of your ticket shop.
|
||||
|
||||
.. thumbnail:: ../../screens/event/settings_display.png
|
||||
:align: center
|
||||
:class: screenshot
|
||||
|
||||
The upper part of the page contains settings that you always need to set specifically for your event. Those are
|
||||
currently:
|
||||
|
||||
Logo image
|
||||
This logo will be shown as a banner above your shop. If you set it, the event name and date will no longer be
|
||||
displayed by the shop, so we suggest to include them in the image yourself. The maximal height of the image is
|
||||
120 pixels and if you want to use the full width, make your image 1140 pixels wide. If the user's screen is
|
||||
smaller, the logo will be scaled down automatically, so it should still be legible at smaller sizes.
|
||||
|
||||
Frontpage text
|
||||
This text will be shown on the front page of your ticket shop, above the list of products. You can use it to explain
|
||||
your product types, give more information on the event or for other general notices.
|
||||
You can use :ref:`Markdown syntax <markdown-guide>` in this field.
|
||||
|
||||
Voucher explanation
|
||||
This text will be shown above the voucher input box. You can use it to explain how to obtain a voucher and use it.
|
||||
|
||||
Show variations of a product expanded by default
|
||||
If this is not checked, a product with variations will be shown as one row in the show by default and will expand
|
||||
into multiple rows once it is clicked on. With this box checked, the variations will be shown as multiple rows
|
||||
right from the beginning.
|
||||
|
||||
Ask search engines not to index the ticket shop
|
||||
If this is checked, we will set a HTML meta attribute asking search engines by Google not to put this ticket shop
|
||||
into their searchable index.
|
||||
|
||||
|
||||
The lower part of the page contains settings that you can **either** set on organizer-level for all your events **or**
|
||||
override for this single event individually. Those are:
|
||||
|
||||
Primary color
|
||||
This color will be used for links, buttons, and other design elements throughout your shop and emails sent to your
|
||||
customers. We suggest not choosing something to light, since text in that color should be readable on a white
|
||||
background and white text should be readable on a background of this color.
|
||||
|
||||
Accent color for success
|
||||
This color will be used for success messages. We suggest to choose a dark shade of green.
|
||||
|
||||
Accent color for errors
|
||||
This color will be used for error messages. We suggest to choose a dark shade of red.
|
||||
|
||||
Font
|
||||
Choose one of multiple fonts to use for your web shop.
|
||||
|
||||
.. note:: Both the color and font settings can take a few seconds up to a few minutes before they become active on your
|
||||
shop.
|
||||
@@ -1,216 +0,0 @@
|
||||
E-mail settings
|
||||
===============
|
||||
|
||||
The settings at "Settings" → "E-mail" allow you to customize the emails that pretix sends to the participants of your
|
||||
event.
|
||||
|
||||
.. thumbnail:: ../../screens/event/settings_email.png
|
||||
:align: center
|
||||
:class: screenshot
|
||||
|
||||
The page is separated into four parts: "E-mail settings", "E-mail design", "E-mail content" and "SMTP settings".
|
||||
We will explain all of them in detail on this page.
|
||||
|
||||
E-mail settings
|
||||
---------------
|
||||
|
||||
The upper part of the page contains settings that are relevant for the generation of all e-mails alike. Those are
|
||||
currently:
|
||||
|
||||
Subject prefix
|
||||
This text will be prepended to the subject of all e-mails that are related to your event. For example, if you
|
||||
set this to "dc2018" all subjects will be formatted like "[dc2018] Your payment was successful".
|
||||
|
||||
Sender address
|
||||
All e-mails will be sent with this address in the "From" field. If you use an email address at a custom domain,
|
||||
we strongly recommend to use the SMTP settings below as well, otherwise your e-mails might be detected as spam
|
||||
due to the `Sender Policy Framework`_ and similar mechanisms.
|
||||
|
||||
Sender name
|
||||
This is the name associated with the sender address. By default, this is your event name.
|
||||
|
||||
Signature
|
||||
This text will be appended to all e-mails in form of a signature. This might be useful e.g. to add your contact
|
||||
details or any legal information that needs to be included with the e-mails.
|
||||
|
||||
Bcc address
|
||||
This email address will receive a copy of every event-related email.
|
||||
|
||||
Attach calendar files
|
||||
With this option, every order confirmation mail will include an ics file with name, date and location of
|
||||
your event. It can be imported into many digital calendars.
|
||||
|
||||
Sales Channels for Checkout Emails
|
||||
When you are using multiple sales channel, you may want to decide that mails for order and payment confirmation
|
||||
are only to be sent for some sales channels. For orders created through the default online shop, these emails
|
||||
must always be send. A similar option is available for ticket download reminders.
|
||||
|
||||
E-mail design
|
||||
-------------
|
||||
|
||||
In this part, you can choose and preview the layout of your emails. More layouts can be added by pretix plugins.
|
||||
|
||||
E-mail content
|
||||
--------------
|
||||
|
||||
The next part of the page allows you to customize the exact texts of all e-mails sent by the system automatically.
|
||||
You can click on the different boxes to expand them and see the texts.
|
||||
|
||||
Within the texts, you can use placeholders that will later by replaced by values depending on the event or order. Below
|
||||
every text box is a list of supported placeholders, but currently the following are defined (not every placeholder
|
||||
is valid in every text):
|
||||
|
||||
============================== ===============================================================================
|
||||
Placeholder Description
|
||||
============================== ===============================================================================
|
||||
event The event name
|
||||
event_slug The event's short form
|
||||
code In case of the waiting list, the voucher code to redeem
|
||||
currency The currency used for the event (three-letter code)
|
||||
total The order's total value
|
||||
total_with_currency The order's total value with a localized currency sign
|
||||
refund_amount (For cancellation emails) The amount of money that will be refunded, including
|
||||
the currency
|
||||
payment_info Information text specific to the payment method (e.g. banking details)
|
||||
url An URL pointing to the download/status page of the order
|
||||
url_info_change An URL pointing to the page of the order that can be used to change ticket
|
||||
information
|
||||
url_products_change An URL pointing to the page of the order that can be used to change the products
|
||||
in the order
|
||||
url_cancel An URL pointing to the page of the order that can be used to cancel the order
|
||||
name, name_* Any name that can be used to address the recipient (e.g. name from invoice address,
|
||||
name from first ticket, …)
|
||||
invoice_name, invoice_name_* The name field of the invoice address
|
||||
invoice_company The company field of the invoice address
|
||||
attendee_name, attendee_name_* The name of the attendee represented by the ticket
|
||||
expire_date The order's expiration date
|
||||
comment When rejecting an order, this will contain the reason for the rejection
|
||||
date The same as ``expire_date``, but in a different e-mail (for backwards
|
||||
compatibility)
|
||||
orders A list of orders including links to their status pages, specific to the "resend
|
||||
link (requested by user)" e-mail
|
||||
hours In case of the waiting list, the number of hours the voucher code is valid
|
||||
product In case of the waiting list, the product that has become available
|
||||
voucher_list When sending out vouchers in bulk, this will be replaced with the list of
|
||||
vouchers
|
||||
============================== ===============================================================================
|
||||
|
||||
The different e-mails are explained in the following:
|
||||
|
||||
Placed Order
|
||||
This e-mail is sent out to every order directly after the order has been received, except if the order total
|
||||
is zero (see below). It should specify that/how the order is to be paid.
|
||||
|
||||
Paid Order
|
||||
This e-mail is sent out as soon as the payment for an order has been received and should give the customer
|
||||
more information on how to proceed, e.g. by downloading their ticket.
|
||||
|
||||
Free Order
|
||||
This e-mail is sent out instead of "Placed Order" and "Paid Order" if the order total is zero. It therefore should
|
||||
tell the same information, except asking the customer for completing their payment.
|
||||
|
||||
Resend link
|
||||
Sent by admin
|
||||
This e-mail will be sent out if you click the "Resend link" next to the e-mail address field on the order detail
|
||||
page. It should include the link to the order and can be sent to users e.g. if they lost their original e-mails.
|
||||
|
||||
Requested by user
|
||||
Customers can also request a link to all orders they created using their e-mail address themselves by filling
|
||||
out a form on the website. In this case, they will receive an e-mail containing a list of all orders they created
|
||||
with the respective links.
|
||||
|
||||
Order changed
|
||||
This e-mail is sent out if you change the content of the order and choose to notify the user about it.
|
||||
|
||||
Payment reminder
|
||||
This e-mail is sent out a certain number of days before the order's expiry date. You can specify the number of days
|
||||
before the expiry date that this should happen and the e-mail will only ever be sent if you do specify such a
|
||||
number. The text should ask the customer to complete the payment, tell the options on how to do so and the
|
||||
consequences if no payment is received (ticket gone, depending on your other settings). You should also include
|
||||
a way to contact you in case of questions.
|
||||
|
||||
Waiting list notification
|
||||
If you enable the waiting list feature, this is the mail that will be sent out if a ticket is assigned to a person on
|
||||
the waiting list. It should include the voucher that needs to be redeemed to get the free spot and tell how long
|
||||
that voucher is valid and where to redeem it.
|
||||
|
||||
Order canceled
|
||||
This e-mail is sent to a customer if their order has been canceled.
|
||||
|
||||
|
||||
Order custom mail
|
||||
You can use pretix' admin interface to directly send an e-mail with a custom text to the customer of a specific
|
||||
order. In this case, this will be the default text and might save you time by not having to re-type all of it every
|
||||
time.
|
||||
|
||||
Reminder to download tickets
|
||||
If you want, you can configure an email that will be send out a number of days before your event to remind
|
||||
attendees to download their tickets. The e-mail should include a link to the ticket download. This e-mail will only
|
||||
ever be sent if you specify a number of days.
|
||||
|
||||
Order approval process
|
||||
If you configure one of your products to "require approval", orders of that product will not immediately be confirmed
|
||||
but only after you approved them manually. In this case, the following e-mail templates will be sent out.
|
||||
|
||||
Received order
|
||||
After an order has been received, this e-mail will be sent automatically instead of the "order placed" e-mail from
|
||||
above.
|
||||
|
||||
Approved order
|
||||
This e-mail will be sent after you manually approved an order. This should include instructions to pay for the order,
|
||||
which is why this will only be used for a paid order. For a free order, the "free order" e-mail from above will
|
||||
be sent.
|
||||
|
||||
Denied order
|
||||
This e-mail will be sent out to customers when their order has been denied.
|
||||
|
||||
SMTP settings
|
||||
-------------
|
||||
|
||||
If you want to send your e-mails via your own e-mail address, we strongly recommend to use SMTP for this purpose.
|
||||
SMTP is a protocol that is used by e-mail clients to communicate with e-mail servers. Using SMTP, pretix can talk to
|
||||
your e-mail service provider the same way that e.g. the e-mail app on your phone can.
|
||||
|
||||
Your e-mail provider will most likely have a document that tells you the settings for the various fields to fill in
|
||||
here (hostname, port, username, password, encryption).
|
||||
|
||||
With the checkbox "Use custom SMTP server" you can turn using your SMTP server on or off completely. With the
|
||||
button "Save and test custom SMTP connection", you can test if the connection and authentication to your SMTP server
|
||||
succeeds, even before turning that checkbox on.
|
||||
|
||||
Spam issues
|
||||
-----------
|
||||
|
||||
If you use an email address of your own domain as a sender address and do not use a custom SMTP server, it is very
|
||||
likely that at least some of your emails will go to the spam folders of their recipients. We **strongly recommend**
|
||||
to use your organization's SMTP server in this case, making your email really come from your organization. If you don't
|
||||
want that or cannot do that, you should add the pretix application server to your SPF record.
|
||||
|
||||
If you are using our hosted service at pretix.eu, you can add the following to your SPF record::
|
||||
|
||||
include:_spf.pretix.eu
|
||||
|
||||
A complete record could look like this::
|
||||
|
||||
v=spf1 a mx include:_spf.pretix.eu ~all
|
||||
|
||||
Make sure to read up on the `SPF specification`_.
|
||||
|
||||
If you want to authenticate your emails with `DKIM`_, set up a ``CNAME`` record for the subdomain ``pretix._domainkey``
|
||||
pointing to ``dkim.pretix.eu``::
|
||||
|
||||
pretix._domainkey.mydomain.com. CNAME dkim.pretix.eu.
|
||||
|
||||
Then, please contact support@pretix.eu and we will enable DKIM for your domain on our mail servers.
|
||||
|
||||
For senders with larger volumes, Google Mail also requires you to have a `DMARC`_ policy (that may however be ``p=none``).
|
||||
|
||||
.. note:: Many SMTP servers impose rate limits on the sent emails, such as a maximum number of emails sent per hour.
|
||||
These SMTP servers are often not suitable for use with pretix, in case you want to send an email to many
|
||||
hundreds or thousands of ticket buyers. Depending on how the rate limit is implemented, emails might be lost
|
||||
in this case, as pretix only retries email delivery for a certain time period.
|
||||
|
||||
.. _DKIM: https://en.wikipedia.org/wiki/DomainKeys_Identified_Mail
|
||||
.. _Sender Policy Framework: https://en.wikipedia.org/wiki/Sender_Policy_Framework
|
||||
.. _SPF specification: http://www.open-spf.org/SPF_Record_Syntax
|
||||
.. _DMARC: https://en.wikipedia.org/wiki/DMARC
|
||||
@@ -1,73 +0,0 @@
|
||||
.. spelling:word-list::
|
||||
|
||||
Warengutschein
|
||||
Wertgutschein
|
||||
|
||||
.. _giftcards:
|
||||
|
||||
Gift cards
|
||||
==========
|
||||
|
||||
Gift cards, also known as "gift coupons" or "gift certificates" are a mechanism that allows you to sell tokens that
|
||||
can later be used to pay for tickets.
|
||||
|
||||
Gift cards are very different feature than **vouchers**. The difference is:
|
||||
|
||||
* Vouchers can be used to give a discount. When a voucher is used, the price of a ticket is reduced by the configured
|
||||
discount and sold at a lower price. They therefore reduce both revenue as well as taxes. Vouchers (in pretix) are
|
||||
always specific to a certain product in an order. Vouchers are usually not sold but given out as part of a
|
||||
marketing campaign or to specific groups of people. Vouchers in pretix are bound to a specific event.
|
||||
|
||||
* Gift cards are not a discount, but rather a means of payment. If you buy a €20 ticket with a €10 gift card, it is
|
||||
still a €20 ticket and will still count towards your revenue with €20. Gift cards are usually bought for the money
|
||||
that they are worth. Gift cards in pretix can be used across events (and even organizers).
|
||||
|
||||
Selling gift cards
|
||||
------------------
|
||||
|
||||
Selling gift cards works like selling every other type of product in pretix: Create a new product, then head to
|
||||
"Additional settings" and select the option "This product is a gift card". Whenever someone buys this product and
|
||||
pays for it, a new gift card will be created.
|
||||
|
||||
In this case, the gift card code corresponds to the "ticket secret" in the PDF ticket. Therefore, if selling gift cards,
|
||||
you can use ticket downloads just as with normal tickets and use our ticket editor to create beautiful gift certificates
|
||||
people can give to their loved ones.
|
||||
|
||||
Of course, you can use pretix' flexible options to modify your product. For example, you can configure that the customer
|
||||
can freely choose the price of the gift card.
|
||||
|
||||
.. note::
|
||||
|
||||
pretix currently does not support charging sales tax or VAT when selling gift cards, but instead charges VAT on
|
||||
the full price when the gift card is redeemed. This is the correct behavior in Germany and some other countries for
|
||||
gift cards which are not bound to a very specific service ("Warengutschein"), but instead to a monetary amount
|
||||
("Wertgutschein").
|
||||
|
||||
.. note::
|
||||
|
||||
The ticket PDF will not contain the correct gift card code before the order has been paid, so we recommend not
|
||||
selling gift cards in events where tickets are issued before payments arrive.
|
||||
|
||||
|
||||
Accepting gift cards
|
||||
--------------------
|
||||
|
||||
All your events have have the payment provider "Gift card" enabled by default, but it will only show up in the ticket
|
||||
shop once the very first gift card has been issued on your organizer account. Of course, you can turn off gift card
|
||||
payments if you do not want them for a specific event.
|
||||
|
||||
If gift card payments are enabled, buyers will be able to select "Gift card" as a payment method during checkout. If
|
||||
a gift card with a value less than the order total is used, the buyer will be asked to select a second payment method
|
||||
for the remaining payment. If a gift card with a value greater than the order total is used, the surplus amount
|
||||
remains on the gift card and can be used in a different purchase.
|
||||
|
||||
If it possible to accept gift cards across organizer accounts. To do so, you need to have access to both organizer
|
||||
accounts. Then, you will see a configuration section at the bottom of the "Gift cards" page of your organizer settings
|
||||
where you can specify which gift cards should be accepted.
|
||||
|
||||
Manually issuing or using gift cards
|
||||
------------------------------------
|
||||
|
||||
Of course, you can also issue or redeem gift cards manually through our backend using the "Gift cards" menu item in your
|
||||
organizer profile or using our API. These gift cards will be tracked by pretix, but do not correspond to any purchase
|
||||
within pretix. You will therefore need to account for them in your books separately.
|
||||
@@ -1,20 +0,0 @@
|
||||
Use case: Early-bird tiers based on dates
|
||||
-----------------------------------------
|
||||
|
||||
Let's say you run a conference that has the following pricing scheme:
|
||||
|
||||
* 12 to 6 months before the event: € 450
|
||||
* 6 to 3 months before the event: € 550
|
||||
* closer than 3 months to the event: € 650
|
||||
|
||||
Of course, you could just set up one product and change its price at the given dates manually, but if you want to set
|
||||
this up automatically, here's how:
|
||||
|
||||
Create three products (e.g. "super early bird", "early bird", "regular ticket") with the respective prices and one shared
|
||||
quota of your total event capacity. Then, set the **available from** and **available until** configuration fields of
|
||||
the products to automatically turn them on and off based on the current date.
|
||||
|
||||
If you're in an event series, this will likely not help you since these dates would need to be the same for all dates
|
||||
in your series. As an alternative, you can go to the "Dates" section of your event series, select one or more dates,
|
||||
and scroll down to the "product settings" section. Here, you can also define availability times for individual products
|
||||
just for this date individually.
|
||||
@@ -1,47 +0,0 @@
|
||||
Use case: Early-bird tiers based on ticket numbers
|
||||
--------------------------------------------------
|
||||
|
||||
Let's say you run a conference with 400 tickets that has the following pricing scheme:
|
||||
|
||||
* First 100 tickets ("super early bird"): € 450
|
||||
* Next 100 tickets ("early bird"): € 550
|
||||
* Remaining tickets ("regular"): € 650
|
||||
|
||||
First of all, create three products:
|
||||
|
||||
* "Super early bird ticket"
|
||||
* "Early bird ticket"
|
||||
* "Regular ticket"
|
||||
|
||||
Then, create three quotas:
|
||||
|
||||
* "Super early bird" with a **size of 100** and the "Super early bird ticket" product selected. At "Advanced options",
|
||||
select the box "Close this quota permanently once it is sold out".
|
||||
|
||||
* "Early bird and lower" with a **size of 200** and both of the "Super early bird ticket" and "Early bird ticket"
|
||||
products selected. At "Advanced options", select the box "Close this quota permanently once it is sold out".
|
||||
|
||||
* "All participants" with a **size of 400**, all three products selected and **no additional options**.
|
||||
|
||||
Next, modify the product "Regular ticket". In the section "Availability", you should look for the option "Only show
|
||||
after sellout of" and select your quota "Early bird and lower". Do the same for the "Early bird ticket" with the quota
|
||||
"Super early bird ticket".
|
||||
|
||||
This will ensure the following things:
|
||||
|
||||
* Each ticket level is only visible after the previous level is sold out.
|
||||
|
||||
* As soon as one level is really sold out, it's not coming back, because the quota "closes", i.e. locks in place.
|
||||
|
||||
* By creating a total quota of 400 with all tickets included, you can still make sure to sell the maximum number of
|
||||
tickets, even if e.g. early-bird tickets are canceled.
|
||||
|
||||
Optionally, if you want to hide the early bird prices once they are sold out, go to "Settings", then "Display" and
|
||||
select "Hide all products that are sold out". Of course, it might be a nice idea to keep showing the prices to remind
|
||||
people to buy earlier next time ;)
|
||||
|
||||
Please note that there might be short time intervals where the prices switch back and forth: When the last early bird
|
||||
tickets are in someone's cart (but not yet sold!), the early bird tickets will show as "Reserved" and the regular
|
||||
tickets start showing up. However, if the customers holding the reservations do not complete their order,
|
||||
the early bird tickets will become available again. This is not avoidable if we want to prevent malicious users
|
||||
from blocking all the cheap tickets without an actual sale happening.
|
||||
@@ -1,44 +0,0 @@
|
||||
Use case: Group discounts
|
||||
-------------------------
|
||||
|
||||
Often times, you want to give discounts for whole groups attending your event.
|
||||
|
||||
Automatic discounts
|
||||
"""""""""""""""""""
|
||||
|
||||
pretix can automatically grant discounts if a certain condition is met, such as a specific group size. To set this up,
|
||||
head to **Products**, **Discounts** in the event navigation and **Create a new discount**. You can choose a name so you
|
||||
can later find this again. You can also optionally restrict the discount to a specific time frame or a specific sales
|
||||
channel.
|
||||
|
||||
Next, either select **Apply to all products** or create a selection of products that are eligible for the discount.
|
||||
|
||||
For a **percentual group discount** similar to "if you buy at least 5 tickets, you get 20 percent off", set
|
||||
**Minimum number of matching products** to "5" and **Percentual discount on matching products** to "20.00".
|
||||
|
||||
For a **buy-X-get-Y discount**, e.g. "if you buy 5 tickets, you get one free", set
|
||||
**Minimum number of matching products** to "5", **Percentual discount on matching products** to "100.00", and
|
||||
**Apply discount only to this number of matching products** to "1".
|
||||
|
||||
Fixed group packages
|
||||
""""""""""""""""""""
|
||||
|
||||
If you want to sell group tickets in fixed sizes, e.g. a table of eight at your gala dinner, you can use product bundles.
|
||||
Assuming you already set up a ticket for admission of single persons, you then set up a second product **Table (8 persons)**
|
||||
with a discounted full price. Then, head to the **Bundled products** tab of that product and add one bundle configuration
|
||||
to include the single admission product **eight times**. Next, create an unlimited quota mapped to the new product.
|
||||
|
||||
This way, the purchase of a table will automatically create eight tickets, leading to a correct calculation of your total
|
||||
quota and, as expected, eight persons on your check-in list. You can even ask for the individual names of the persons
|
||||
during checkout.
|
||||
|
||||
Minimum order amount
|
||||
""""""""""""""""""""
|
||||
|
||||
If you want to promote discounted group tickets in your price list, you can also do so by creating a special
|
||||
**Group ticket** at the reduced per-person price and set the **Minimum amount per order** option of the ticket to the minimal
|
||||
group size.
|
||||
|
||||
For more complex use cases, you can also use add-on products that can be chosen multiple times.
|
||||
|
||||
This way, your ticket can be bought an arbitrary number of times – but no less than the given minimal amount per order.
|
||||
@@ -1,21 +0,0 @@
|
||||
Use case: Mixed taxation
|
||||
------------------------
|
||||
|
||||
Let's say you are a charitable organization in Germany and are allowed to charge a reduced tax rate of 7% for your educational event. However, your event includes a significant amount of food, you might need to charge a 19% tax rate on that portion. For example, your desired tax structure might then look like this:
|
||||
|
||||
* Conference ticket price: € 450 (incl. € 150 for food)
|
||||
|
||||
* incl. € 19.63 VAT at 7%
|
||||
* incl. € 23.95 VAT at 19%
|
||||
|
||||
You can implement this in pretix using product bundles. In order to do so, you should create the following two products:
|
||||
|
||||
* Conference ticket at € 450 with a 7% tax rule
|
||||
* Conference food at € 150 with a 19% tax rule and the option "**Only sell this product as part of a bundle**" set
|
||||
|
||||
In addition to your normal conference quota, you need to create an unlimited quota for the food product.
|
||||
|
||||
Then, head to the **Bundled products** tab of the "conference ticket" and add the "conference food" as a bundled product with a **designated price** of € 150.
|
||||
|
||||
Once a customer tries to buy the € 450 conference ticket, a sub-product will be added and the price will automatically be split into the two components, leading to a correct computation of taxes.
|
||||
|
||||
@@ -1,78 +0,0 @@
|
||||
Use case: Discounted packages
|
||||
-----------------------------
|
||||
|
||||
Imagine you run a trade show that opens on three consecutive days and you want to have the following pricing:
|
||||
|
||||
* Single day: € 10
|
||||
* Any two days: € 17
|
||||
* All three days: € 25
|
||||
|
||||
In this case, there are multiple different ways you could set this up with pretix.
|
||||
|
||||
Option A: Combination products
|
||||
""""""""""""""""""""""""""""""
|
||||
|
||||
With this option, you just set up all the different combinations someone could by as a separate product. In this case, you would need 7 products:
|
||||
|
||||
* Day 1 pass
|
||||
* Day 2 pass
|
||||
* Day 3 pass
|
||||
* Day 1+2 pass
|
||||
* Day 2+3 pass
|
||||
* Day 1+3 pass
|
||||
* All-day pass
|
||||
|
||||
Then, you create three quotas, each one with the maximum capacity of your venue on any given day:
|
||||
|
||||
* Day 1 quota, linked to "Day 1 pass", "Day 1+2 pass", "Day 1+3 pass", and "All-day pass"
|
||||
* Day 2 quota, linked to "Day 2 pass", "Day 1+2 pass", "Day 2+3 pass", and "All-day pass"
|
||||
* Day 3 quota, linked to "Day 3 pass", "Day 2+3 pass", "Day 1+3 pass", and "All-day pass"
|
||||
|
||||
This way, every person gets exactly one ticket that they can use for all days that they attend. You can later set up check-in lists appropriately to make sure only tickets valid for a certain day can be scanned on that day.
|
||||
|
||||
The benefit of this option is that your product structure and order structure stays very simple. However, the two-day packages scale badly when you need many products.
|
||||
|
||||
We recommend this setup for most setups in which the number of possible combinations does not exceed the number of parts (here: number of days) by much.
|
||||
|
||||
Option B: Add-ons and bundles
|
||||
"""""""""""""""""""""""""""""
|
||||
|
||||
We can combine the two features "product add-ons" and "product bundles" to set this up in a different way. Here, you would create the following five products:
|
||||
|
||||
* Day 1 pass in a category called "Day passes"
|
||||
* Day 2 pass in a category called "Day passes"
|
||||
* Day 3 pass in a category called "Day passes"
|
||||
* Two-day pass
|
||||
* All-day pass
|
||||
|
||||
This time, you will need five quotas:
|
||||
|
||||
* Day 1 quota, linked to "Day 1 pass"
|
||||
* Day 2 quota, linked to "Day 2 pass"
|
||||
* Day 3 quota, linked to "Day 3 pass"
|
||||
* Two-day pass quota, linked to "Two-day pass" (can be unlimited)
|
||||
* All-day pass quota, linked to "All-day pass" (can be unlimited)
|
||||
|
||||
Then, you open the "Add-On" tab in the settings of the **Two-day pass** product and create a new add-on configuration specifying the following options:
|
||||
|
||||
* Category: "Day passes"
|
||||
* Minimum number: 2
|
||||
* Maximum number: 2
|
||||
* Add-Ons are included in the price: Yes
|
||||
|
||||
This way, when buying a two-day pass, the user will be able to select *exactly* two days for free, which will then be added to the cart. Depending on your specific configuration, the user will now receive *two separate* tickets, one for each day.
|
||||
|
||||
For the all-day pass, you open the "Bundled products" tab in the settings of the **All-day pass** product and add **three** new bundled items with the following options:
|
||||
|
||||
* Bundled product: "Day 1/2/3"
|
||||
* Bundled variation: None
|
||||
* Count: 1
|
||||
* Designated price: 0
|
||||
|
||||
This way, when buying an all-day pass, three free day passes will *automatically* be added to the cart. Depending on your specific configuration, the user will now receive *three separate* tickets, one for each day.
|
||||
|
||||
This approach makes your order data more complicated, since e.g. someone who buys an all-day pass now technically bought **four products**. However, this option allows for more flexibility when you have lots of options to choose from.
|
||||
|
||||
.. tip::
|
||||
|
||||
Depending on the packages you offer, you **might not need both the add-on and the bundle feature**, i.e. you only need the add-on feature for the two-day pass and only the bundle feature for the all-day pass. You could also set up the two-day pass like we showed here, but the all-day pass like in option A!
|
||||
@@ -1,13 +0,0 @@
|
||||
Use case: Multiple price levels
|
||||
-------------------------------
|
||||
|
||||
Imagine you're running a concert with general admission that sells a total of 200 tickets for two prices:
|
||||
|
||||
* Regular: € 25.00
|
||||
* Students: € 19.00
|
||||
|
||||
You can either set up two different products called e.g. "Regular ticket" and "Student ticket" with the respective prices, or two variations within the same product. In this simple case, it really doesn't matter.
|
||||
|
||||
In addition, you will need quotas. If you do not care how many of your tickets are sold to students, you should set up just **one quota** of 200 called e.g. "General admission" that you link to **both products**.
|
||||
|
||||
If you want to limit the number of student tickets to 50 to ensure a certain minimum revenue, but do not want to limit the number of regular tickets artificially, we suggest you to create the same quota of 200 that is linked to both products, and then create a **second quota** of 50 that is only linked to the student ticket. This way, the system will reduce both quotas whenever a student ticket is sold and only the larger quota when a regular ticket is sold.
|
||||
@@ -1,28 +0,0 @@
|
||||
Use case: Restricted audience
|
||||
-----------------------------
|
||||
|
||||
Not all events are for everyone. Sometimes, there is a good reason to restrict access to your event or parts of your event only to a specific, invited group. There's two ways to implement this with pretix:
|
||||
|
||||
Option A: Required voucher codes
|
||||
""""""""""""""""""""""""""""""""
|
||||
|
||||
If you check the option "**This product can only be bought using a voucher**" of one or multiple products, only people holding an applicable voucher code will be able to buy the product.
|
||||
|
||||
You can then generate voucher codes for the respective product and send them out to the group of possible attendees. If the recipients should still be able to choose between different products, you can create an additional quota and map the voucher to that quota instead of the products themselves.
|
||||
|
||||
There's also the second option "**This product will only be shown if a voucher matching the product is redeemed**". In this case, the existence of the product won't even be shown before a voucher code is entered – useful for a VIP option in a shop where you also sell other products to the general public. Please note that this option does **not** work with vouchers assigned to a quota, only with vouchers assigned directly to the product.
|
||||
|
||||
This option is appropriate if you know the group of people beforehand, e.g. members of a club, and you can mail them their access codes.
|
||||
|
||||
Option B: Order approvals
|
||||
"""""""""""""""""""""""""
|
||||
|
||||
If you do not know your audience already, but still want to restrict it to a certain group, e.g. people with a given profession, you can check the "**Buying this product requires approval**" in the settings of your product. If a customer tries to buy such a product, they will be able to place their order but can not proceed to payment. Instead, you will be asked to approve or deny the order and only if you approve it, we will send a payment link to the customer.
|
||||
|
||||
This requires the customer to interact with the ticket shop twice (once for the order, once for the payment) which adds a little more friction, but gives you full control over who attends the event.
|
||||
|
||||
Option C: Registered customers & memberships
|
||||
""""""""""""""""""""""""""""""""""""""""""""
|
||||
|
||||
You can also do this by requiring that customers have a customer account and an active membership. You can find more
|
||||
information on this mechanism in the :ref:`seasontickets` article.
|
||||
@@ -1,92 +0,0 @@
|
||||
.. _seasontickets:
|
||||
|
||||
Use case: Season tickets
|
||||
========================
|
||||
|
||||
Season tickets and similar time-based tickets are popular for swimming pools, sports clubs, theaters and lots of other
|
||||
types of venues. In this article, we show you different ways to set them up with pretix. Of course, other types of
|
||||
tickets such as week tickets, month tickets or tickets of ten can be created with the same mechanism.
|
||||
|
||||
There is a big difference between the two ways we show below.
|
||||
|
||||
With **Option A**, a customer who purchases a season ticket creates an account with their email address and a password
|
||||
and the season ticket will be saved in that account. If the customer wants to use the season ticket, they need to buy
|
||||
an additional free ticket for the specific event they want to visit. This makes sense for all events or venues with
|
||||
**limited capacity** or **reserved seating**, because it still allows you to set an upper limit of people showing up
|
||||
for a specific event or time slot.
|
||||
|
||||
With **Option B**, a customer who purchases a season ticket receives a single ticket with a single QR code that can be
|
||||
used an unlimited number of times. This makes sense if the capacity of your venue is virtually unlimited and you do not
|
||||
need to know in advance how many season ticket holders will show up.
|
||||
|
||||
Option A: Memberships and multiple tickets
|
||||
""""""""""""""""""""""""""""""""""""""""""
|
||||
|
||||
Since this approach requires customers to be identified with a customer account, you first need to enable the customer
|
||||
accounts feature in your organizer settings in the "Customer accounts" tab.
|
||||
|
||||
.. thumbnail:: ../../../screens/event/seasontickets_orgsettings.png
|
||||
:align: center
|
||||
:class: screenshot
|
||||
|
||||
After doing so, a new menu item "Customer accounts" will also show up in the main menu of your organizer account on
|
||||
the left. Open it's menu and click on "Membership types". Then, select to "create a new membership type".
|
||||
|
||||
You can name the membership type in a way that clearly explains where it is valid, e.g. "season pass main location"
|
||||
or "season pass all locations". There are a few details you can configure on this page, such as whether the season pass
|
||||
can be used by multiple different persons, or if the season pass can be used for multiple tickets for the same time
|
||||
slot. You can also define a maximum number of usages, which is useful if you e.g. use this feature to add a "ticket of
|
||||
ten".
|
||||
|
||||
.. thumbnail:: ../../../screens/event/seasontickets_membershiptype.png
|
||||
:align: center
|
||||
:class: screenshot
|
||||
|
||||
Next, you need a way of selling these season passes. Theoretically this can be done through the same event series that
|
||||
you usually use, but it's probably cleaner and easier to find for customers if you create a **new event** that you only
|
||||
use to sell season passes. The start and end date of the new event should correspond to the dates of your season.
|
||||
|
||||
Inside the new event, you only need to create a single product which you can call "season ticket". Inside that product's
|
||||
settings, head to the "Additional settings" section and look for the option "This product creates a membership of type".
|
||||
Select the membership type you just created. By default, the checkbox "The duration of the membership is the same as the
|
||||
duration of the event or event series date" is active, which is fine for our season ticket example, but you might need
|
||||
to unset it and provide custom timing for other ticket types such as week passes.
|
||||
|
||||
.. thumbnail:: ../../../screens/event/seasontickets_issue.png
|
||||
:align: center
|
||||
:class: screenshot
|
||||
|
||||
To prevent confusion, it might be useful to turn off ticket downloading at "Settings" → "Tickets" for your new event.
|
||||
That's it, you are now ready to sell season tickets!
|
||||
|
||||
We can now deal with how to use the season tickets. Move back to your existing event and create a new product
|
||||
**or** product variation of your regular product which you call "ticket for season ticket holders" and assign a price
|
||||
of zero. In the "Availability" section of the product or variation settings, check the option "Require a valid
|
||||
membership" and again select the membership type you created. You can of course repeat this with all events the season
|
||||
ticket holder should have access to.
|
||||
|
||||
.. thumbnail:: ../../../screens/event/seasontickets_require.png
|
||||
:align: center
|
||||
:class: screenshot
|
||||
|
||||
Option B: All-access in a single pass
|
||||
"""""""""""""""""""""""""""""""""""""
|
||||
|
||||
If you have only a single event series with many time slots and you do not care how many season ticket holders show up,
|
||||
there's a solution that does not require your customers to set up accounts and book a new ticket on every visit.
|
||||
|
||||
Instead, you can just create an additional product "Season ticket" that you enable either in a "special" date of your
|
||||
event series just created for this purpose, or in all of your dates so it can be easily found by customers.
|
||||
|
||||
Then, you can set up your check-in lists with custom logic in the "Advanced" tab of your check-in list settings.
|
||||
The logic needs to ensure the following requirements:
|
||||
|
||||
* Regular ticket holders can only get in during their assigned time frame **and** when they haven't used their ticket before.
|
||||
|
||||
* Season ticket holders can always get in.
|
||||
|
||||
Here's an example on how to set this up:
|
||||
|
||||
.. thumbnail:: ../../../screens/event/seasontickets_rules.png
|
||||
:align: center
|
||||
:class: screenshot
|
||||
@@ -1,24 +0,0 @@
|
||||
Terminology
|
||||
-----------
|
||||
|
||||
Products
|
||||
A product is a basic entity that can be bought. You can think of it as a ticket type, but it can be more things than just a ticket, it can also be a piece of merchandise, a parking slot, etc.
|
||||
You might find some places where they are called "items" instead, but we're trying to get rid of that.
|
||||
|
||||
Product categories
|
||||
Products can be sorted into categories. Each product can only be in one category. Category are mostly used for grouping related products together to make your event page easier to read for buyers. However, we'll need categories as well to set up some of the structures outlined below.
|
||||
|
||||
Product variations
|
||||
During creation of a product, you can decide that your product should have multiple variations. Variations of a product can differ in price, description, and availability, but are otherwise the same. You could use this e.g. for differentiating between a regular ticket and a discounted ticket for students, or when selling merchandise to differentiate the different sizes of a t-shirt.
|
||||
|
||||
Product add-ons
|
||||
Add-ons are products that are sold together with another product (which we will call the base product in this case). For example, you could have a base product "Conference ticket" and then define multiple workshops that can be chosen as an add-on.
|
||||
|
||||
Product bundles
|
||||
Bundles work very similarly to add-ons, but are different in the way that they are always automatically included with the base product and cannot be optional. In contrast to add-on products, the same product can be included multiple times in a bundle.
|
||||
|
||||
Quotas
|
||||
Quotas define the availability of products. A quota has a size (i.e. the number of products in the inventory) and is mapped to one or multiple products or variations.
|
||||
|
||||
Questions
|
||||
Questions are user-defined form fields that buyers will need to fill out when purchasing a product.
|
||||
@@ -1,94 +0,0 @@
|
||||
.. _timeslots:
|
||||
|
||||
Use case: Time slots
|
||||
====================
|
||||
|
||||
A more advanced use case of pretix is using pretix for time-slot-based access to an area with a limited visitor
|
||||
capacity, such as a museum or other attraction. This guide will show you the quickest way to set up such an event
|
||||
with pretix.
|
||||
|
||||
First of all, when creating your event, you need to select that your event represents an "event series":
|
||||
|
||||
|
||||
.. thumbnail:: ../../../screens/event/create_step1.png
|
||||
:align: center
|
||||
:class: screenshot
|
||||
|
||||
You can click :ref:`here <subevents>` for a more general description of event series with pretix, but everything you
|
||||
need to know is in this chapter as well.
|
||||
|
||||
General event setup
|
||||
-------------------
|
||||
|
||||
Before you go further, set up your products that you want to sell for each time slot, such as different types of entry.
|
||||
|
||||
Creating slots
|
||||
--------------
|
||||
|
||||
To create the time slots, you need to create a number of "dates" in the event series. Select "Dates" in the navigation
|
||||
menu on the left side and click "Create many new dates". Then, first enter the pattern of your opening days. In the
|
||||
example, the museum is open week Tuesday to Sunday. We recommend to create the slots for a few weeks at a time, but not
|
||||
e.g. for a full year, since it will be more complicated to change things later.
|
||||
|
||||
.. thumbnail:: ../../../screens/event/timeslots_create.png
|
||||
:align: center
|
||||
:class: screenshot
|
||||
|
||||
Then, scroll to the times section and create your time slots. You can do any interval you like. If you have different
|
||||
opening times on different week days, you will need to go through the creation process multiple times.
|
||||
|
||||
.. thumbnail:: ../../../screens/event/timeslots_create_2.png
|
||||
:align: center
|
||||
:class: screenshot
|
||||
|
||||
Scroll further down and create one or multiple quotas that define how many people can book a ticket for that time slot.
|
||||
In this example, 50 people in total are allowed to enter within every slot:
|
||||
|
||||
.. thumbnail:: ../../../screens/event/timeslots_create_3.png
|
||||
:align: center
|
||||
:class: screenshot
|
||||
|
||||
Do **not** create a check-in list at this point. We will deal with this further below in the guide.
|
||||
Now, press "Save" to create your slots.
|
||||
|
||||
.. warning:: If you create a lot of time slots at once, the server might need a few minutes to create them all in our
|
||||
system. If you receive an error page because it took too long, please do not try again immediately but wait
|
||||
for a few minutes. Most likely, the slots will be created successfully even though you saw an error.
|
||||
|
||||
Event settings
|
||||
--------------
|
||||
|
||||
We recommend that you navigate to "Settings" > "General" > "Display" and set the settings "Default overview style"
|
||||
to "Week calendar":
|
||||
|
||||
.. thumbnail:: ../../../screens/event/timeslots_settings_1.png
|
||||
:align: center
|
||||
:class: screenshot
|
||||
|
||||
Now, your ticket shop should give users a nice weekly overview over all time slots and their availability:
|
||||
|
||||
.. thumbnail:: ../../../screens/event/timeslots_presale.png
|
||||
:align: center
|
||||
:class: screenshot
|
||||
|
||||
Check-in
|
||||
--------
|
||||
|
||||
If you want to scan people at the entrance of your event and only admit them at their designated time, we recommend
|
||||
the following setup: Go to "Check-in" in the main navigation on the left and create a new check-in list. Give it a name
|
||||
and do *not* choose a specific data. We will use one check-in list for all dates. Then, go to the "Advanced" tab at
|
||||
the top and set up two restrictions to make sure people can only get in during the time slot they registered for.
|
||||
You can create the rules exactly like shown in the following screenshot:
|
||||
|
||||
.. thumbnail:: ../../../screens/event/timeslots_checkinlists.png
|
||||
:align: center
|
||||
:class: screenshot
|
||||
|
||||
If you want, you can enter a tolerance of e.g. "10" if you want to be a little bit more relaxed and admit people up to
|
||||
10 minutes before or after their time slot.
|
||||
|
||||
Now, download our `Android or Desktop app`_ and register it to your account. The app will ask you to select one the
|
||||
time slots, but it does not matter, you can select any one of them and then select your newly created check-in list.
|
||||
That's it, you're good to go!
|
||||
|
||||
.. _Android or Desktop app: https://pretix.eu/about/en/scan
|
||||
@@ -1,17 +0,0 @@
|
||||
Use case: Up-selling of ticket extras
|
||||
-------------------------------------
|
||||
|
||||
Let's assume you're putting up a great music festival, and to save trouble with handling payments on-site, you want to sell parking spaces together with your ticket. By using our add-on feature, you can prompt all users to book the parking space (to make sure they see it) and ensure that only people with a ticket can book a parking space. You can set it up like this:
|
||||
|
||||
* Create a base product "Festival admission"
|
||||
* Create a quota for the base product
|
||||
* Create a category "Ticket extras" and check "Products in this category are add-on products"
|
||||
* Create a product "Parking space" within that category
|
||||
* Create a quota for the parking space product
|
||||
* Go to the base product and select the tab "Add-Ons" at the top. Click "Add a new add-on" and choose the "Ticket extras" category. You can keep the numbers at 0 and 1.
|
||||
|
||||
During checkout, all buyers of the base product will now be prompted if they want to add the parking space.
|
||||
|
||||
.. tip::
|
||||
|
||||
You can also use add-on products for free things, just to keep tabs on capacity.
|
||||
@@ -1,77 +0,0 @@
|
||||
Use case: Conference with workshops
|
||||
-----------------------------------
|
||||
|
||||
When running a conference, you might also organize a number of workshops with smaller capacity. To be able to plan, it would be great to know which workshops an attendee plans to attend.
|
||||
|
||||
Option A: Questions
|
||||
"""""""""""""""""""
|
||||
|
||||
Your first and simplest option is to just create a multiple-choice question. This has the upside of making it easy for users to change their mind later on, but will not allow you to restrict the number of attendees signing up for a given workshop – or even charge extra for a given workshop.
|
||||
|
||||
Option B: Add-on products with fixed time slots
|
||||
"""""""""""""""""""""""""""""""""""""""""""""""
|
||||
|
||||
The usually better option is to go with add-on products. Let's take for example the following conference schedule, in which the lecture can be attended by anyone, but the workshops only have space for 20 persons each:
|
||||
|
||||
==================== =================================== ===================================
|
||||
Time Room A Room B
|
||||
==================== =================================== ===================================
|
||||
Wednesday morning Lecture
|
||||
Wednesday afternoon Workshop A Workshop B
|
||||
Thursday morning Workshop C Workshop D (20 € extra charge)
|
||||
==================== =================================== ===================================
|
||||
|
||||
Assuming you already created one or more products for your general conference admission, we suggest that you additionally create:
|
||||
|
||||
* A category called "Workshops" with the checkbox "Products in this category are add-on products" activated
|
||||
|
||||
* A free product called "Wednesday afternoon" within the category "Workshops" and with two variations:
|
||||
|
||||
* Workshop A
|
||||
|
||||
* Workshop B
|
||||
|
||||
* A free product called "Thursday morning" within the category "Workshops" and with two variations:
|
||||
|
||||
* Workshop C
|
||||
|
||||
* Workshop D with a price of 20 €
|
||||
|
||||
* Four quotas for each of the workshops
|
||||
|
||||
* One add-on configuration on your base product that allows users to choose between 0 and 2 products from the category "Workshops"
|
||||
|
||||
Option C: Add-on products with variable time slots
|
||||
""""""""""""""""""""""""""""""""""""""""""""""""""
|
||||
|
||||
The above option only works if your conference uses fixed time slots and every workshop uses exactly one time slot. If
|
||||
your schedule looks like this, it's not going to work great:
|
||||
|
||||
+-------------+------------+-----------+
|
||||
| Time | Room A | Room B |
|
||||
+=============+============+===========+
|
||||
| 09:00-11:00 | Talk 1 | Long |
|
||||
+-------------+------------+ Workshop 1|
|
||||
| 11:00-13:00 | Talk 2 | |
|
||||
+-------------+------------+-----------+
|
||||
| 14:00-16:00 | Long | Talk 3 |
|
||||
+-------------+ workshop 2 +-----------+
|
||||
| 16:00-18:00 | | Talk 4 |
|
||||
+-------------+------------+-----------+
|
||||
|
||||
In this case, we recommend that you go to *Settings*, then *Plugins* and activate the plugin **Agenda constraints**.
|
||||
|
||||
Then, create a product (without variations) for every single part that should be bookable (talks 1-4 and long workshops
|
||||
1 and 2) as well as appropriate quotas for each of them.
|
||||
|
||||
All of these products should be part of the same category. In your base product (e.g. your conference ticket), you
|
||||
can then create an add-on product configuration allowing users to add products from this category.
|
||||
|
||||
If you edit these products, you will be able to enter the "Start date" and "End date" of the talk or workshop close
|
||||
to the bottom of the page. If you fill in these values, pretix will automatically ensure no overlapping talks are
|
||||
booked.
|
||||
|
||||
.. note::
|
||||
|
||||
This option is currently only available on pretix Hosted. If you are interested in using it with pretix Enterprise,
|
||||
please contact sales@pretix.eu.
|
||||
|
Before Width: | Height: | Size: 3.0 KiB |