We currently use stripe.js, but we could use the traditional API for people without JavaScript.

Are they being used correctly everywhere?

e.g. Sep 5-9th instead of Sep 5th - Sep 9th and similar

• Cart / Checkout
• Login
• Viewing and changing orders
• Downloading tickets
• Forgot password, etc.

• When adding things to cart
• When submitting an order with expired card positions
• When receiving payments for an expired order

The pretix control panel allows the administrator to view a list of all orders. It should be made possible to sort this list by various columns (like date, value, …) clicking on the table heads.

A 'password reset' feature should email the user a token to reset his or her password.

• XeLaTeX – bloaty, but produces nice output
• fpdf – nope, crappy software
• SVG – unable to do word wrapping, but this might be the only blocker

The EventSetting/OrganizerSetting models provide a way of storing event-like settings.

• Use them for more things that are currently fields of the Event model (payment term, plugins, …)
• Provide a form/UI for changing them

see https://stripe.com/docs/api#errors

The biggest problem is to tell day-first (europe) from month-first (US).

• Start and end time of presale
• End of payment period
• Start of ticket downloading period

Currently, tax rates are only specified on item-level. However, if a special payment method adds e.g. a credit card fee, this does not directly belong to a special item but might still need a tax rate configured.

PayPal can mark payment objects as pending. We should check them for completion using web hooks. The same goes for refunds and therefore also for stripe.
https://developer.paypal.com/docs/integration/direct/rest-webhooks-overview/
https://stripe.com/docs/api#events

for

• E-Mail sending
• PDF generation
• Exports

Hey! If you ever wanted to contribute to an Open Source project, but didn't know how, you just found a perfect place to start. We try to write this issue as instructive as possible, but as we're humans we almost certainly forgot to write something important in here. If you want to try to tackle this issue and get stuck at any point, please do not hesitate and ask us, either here on GitHub or via email at [email protected]. We'll be very happy to help!

We think this issue is very suitable to people who are just starting with Python or Django development or who never contributed to Open Source before. We'd like to ask people with wide experience in these areas to leave this issue to beginners. Thanks! (If you want something more advanced, just drop us a line, we'll find something 😉)

How to get started

First of all, you need pretix running locally on your machine. We have a guide on the developer installation over here. Play around with it and get a feeling for what pretix is and how it works :) Try to find the places in the interface mentioned in this issue where something needs to change. Maybe try to find the same places in the code? Just searching for characteristic words can be a powerful tool to find your way around.

What this is about

Every event organized by pretix gets a small web page representing the event -- it's ticket shop. In the HTML code of this page we want to add microdata markup. Microdata is a structured way to tell search engines what the given page is about and allows them to understand the page better and do fancy things like showing the event location or date directly in the search results.

How to do this

First, you need to read up a bit about structured data. For example, there is the JSON-LD data format that we probably want to use. Don't get discouraged by complicated-sounding words, just keep to the examples, they should be pretty clear in many cases. Google also has a lot of documentation and tools on the topic, for example:

• A short JSON-LD guide
• A number of examples specifically for events
• A test tool to check if your structured data is good

Once you know how it should look like, you basically only have to put it in the right place, which is src/pretix/presale/templates/pretixpresale/event/index.html, and fill it up with the correct data via template variables.

I want to give it a try!

You're still reading, nice! If you want to try working on this, please comment below, so everyone else knows this is being looked at and can search for a different place to contribute.

First, fork the repository to your own GitHub account. Then clone it locally (or set it as your remote if you already cloned it earlier) and prepare your pull requests. There are a number of tutorials on the Pull Request workflow online, for example this short version by GitHub itself and this more in-depth tutorial. We're excited to see your pull request!

And don't forget: If you get stuck, don't hestitate to ask. We bound ourselves to a Code of Conduct and we're committed to providing a welcoming experience and giving constructive, friendly and useful feedback on your contributions.

Internationalisation features for item names, categories, …

We already have tixlcontrol.views.event.EventUpdate but no process for creating new events. For the beginning, this can be a simple creation form.

Later, this should become a multi-step wizard enabling users to select from multiple presets to initialize the event with.

• List of orders
• Order details
• Switching between order states
• Switching payment methods
• Expand payment term

A required question of type boolean should require the user to select either Yes or No, but currently requires the user to select Yes (because the checkbox is otherwise not checked). A SelectInput could be the solution to this.

We already have tixlcontrol.views.item.ItemUpdate for changing items. It should be easy to implement ItemCreate in a similar matter.

The admin panel should be able to import CSV files to process payments. See the statementmagic subproject.

• Stepping back or forward
• Answering questions for multiple items: Accordion members should have a 'continue' button and open the next one automatically
• Proper field error reporting for questions (accordion should open / be red)

There should be a button or checkbox to take the whole shop up or down. If it is down, it should be only visible to the admin.

This might be easily implemented as a event setting.

In a second step, a checklist of actions might be enforced before going live, e.g. at least one payment provider selected.

We want to move to Django 1.8a1 as soon as possible, as we want to use the new template engine features as early as possible (and maybe move to Jinja2). However, the following issues block the move:

• Django debug toolbar issue #668
• cleanerversion issue #46

On our side, we'll have to adopt in the following ways:

• Adjust to the new template settings
• Use setUpTestDate to improve test performance
• Get rid of strings in urlpatterns

• Hide links the users has no permission for
• Add an editor for event permissions
• Add an editor for organizer permissions
• Add a nice editor for teams/permissions
• Restructure permissions such that plugins can define them

• Configurable positions and sizes
• Own background PDFs
• Configurable fonts
• Drag&drop editor

For setups with high load

…or changing the payment method later if it failed.

Re-try is currently implemented in the PayPal provider, but it would nice to implement it on a higher level for all providers (maybe based on flag providers can set).

• Build new API
• Implement API for stripe
• Implement API for PayPal

If you have an expired CartPosition and you try to add something else to your cart, pretix will try to renew all your CartPositions in order to have a common expiration time for all of them (for user convenience). Currently, this happens by them being removed and added like new positions. This loses all existing information like attendee_name or existion QuestionAnswer objects (which should be retained).

Currently, when a payment provider defines input fields with required=True, they will be rendered with the required=required HTML attribute. This is bad, as there are often multiple payment providers on one page and the user shouldn't need to fill out all of them.

Currently, product descriptions and category descriptions only allow plain text.

This issue suggests to add support for Markdown markup to allow links and other simple formatting.

Implement the user settings dialog

• Change password
• Change e-mail address
• Change name, etc.

Double-check that cleanerversion is used correctly everywhere.