Plugin quality checklist¶
If you want to write a high-quality pretix plugin, this is a list of things you should check before you publish it. This is also a list of things that we check, if we consider installing an externally developed plugin on our hosted infrastructure.
The plugin is clearly licensed under an appropriate license.
The plugin has an unambiguous name, description, and author metadata.
The plugin has a clear versioning scheme and the latest version of the plugin is kept compatible to the latest stable version of pretix.
The plugin is properly packaged using standard Python packaging tools.
The plugin correctly declares its external dependencies.
A contact address is provided in case of security issues.
If any signal receivers use the dispatch_uid feature, the UIDs are prefixed by the plugin’s name and do not clash with other plugins.
If any templates or static files are shipped, they are located in subdirectories with the name of the plugin and do not clash with other plugins or core files.
Any keys stored to the settings store are prefixed with the plugin’s name and do not clash with other plugins or core.
Any keys stored to the user session are prefixed with the plugin’s name and do not clash with other plugins or core.
Any registered URLs are unlikely to clash with other plugins or future core URLs.
All important actions are logged to the shared log storage and a signal receiver is registered to provide a human-readable representation of the log entry.
All views require appropriate permissions and use the
event_urlsmechanism if appropriate. Read more
Any session data for customers is stored in the cart session system if appropriate.
If the plugin is a payment provider:
No credit card numbers may be stored within pretix.
A notification/webhook system is implemented to notify pretix of any refunds.
If such a webhook system is implemented, contents of incoming webhooks are either verified using a cryptographic signature or are not being trusted and all data is fetched from an API instead.
No personal data is stored that is not required for the plugin’s functionality.
For any personal data that is saved to the database, an appropriate data shredder is provided that offers the data for download and then removes it from the database (including log entries).
All user-facing strings in templates, Python code, and templates are wrapped in gettext calls.
No languages, time zones, date formats, or time formats are hardcoded.
Installing the plugin automatically compiles
.mofiles. This is fulfilled automatically if you use the
setup.pyfile form our plugin cookiecutter.
If the plugin adds any database models or relationships from the settings storage to database models, it registers a receiver to the
If the plugin is a payment provider:
A webhook-like system is implemented if payment confirmations are not sent instantly.
Refunds are implemented, if possible.
In case of overpayment or external refunds, an external refund is properly created.
If the plugin adds steps to the checkout process, it has been tested in combination with the pretix widget.
G. Code quality¶
isort and flake8 are used to ensure consistent code styling.
Unit tests are provided for important pieces of business logic.
Functional tests are provided for important interface parts.
Tests are provided to check that permission checks are working.
Continuous Integration is set up to check that tests are passing and styling is consistent.
H. Specific to pretix.eu¶
pretix.eu integrates the data stored by this plugin with its data report features.
pretix.eu integrates this plugin in its generated privacy statements, if necessary.