Hi,

please don't spread the bad habit of using flags to indicate languages.

See https://www.w3.org/International/questions/qa-link-lang and http://www.flagsarenotlanguages.com/blog/why-flags-do-not-represent-language/ for explainations why.

Instead, please use the language name in the language itself, so "English / Deutsch" in this case or more generally عربية (Arabiya) Български (Bəlgarski) català česky dansk Ελληνικά (Ellinika) English español Esperanto فارسی (Farsi) français Galego 한국어 (Hangul) Հայերեն (hayeren) hrvatski Indonesia Italiano עברית (ivrit) Lietuvių magyar Nederlands 日本語 (Nihongo) norsk (bokmål) polski Português română Русский (Russkij) slovensky suomi svenska தமிழ் (Tamil) Tiếng Việt Türkçe українська (ukrajins'ka) 中文(简) 中文(HK) 中文(繁) .

To make things worse, the flags dont even have an alt- or title-attribute, so accessibility is also not given.

Thanks for maintaining this useful software! (Besides this little glitch) I love the UI!

This PR adds the necessary datatypes to provide prometheus-like instrumentation natively to pretix.

Currently supported by this PR are Counters and Gauges.

We've had feedback from multiple users that they were confused by the unlabelled input fields for item counts on the ticket page (see e.g. https://pretix.eu/demo/democon/). The issue may be more pronounced with multiple tickets with longer descriptions.

The fact that a user has to enter a number into that field to order a ticket isn't evident and the purpose of the field isn't visible anywhere on the page. Using the current design one could for example misuse the place holder as a label or maybe add an input group add-on to the count input as well.

If the last date of payments is set to a value before the end of the presale period, users can buy tickets but never pay them. This is probably not a situation anyone wants to have :)

We should validate in the settings form that this cannot be set this way.

After updating to 1.10.0, I tested to create a checkin list as PDF. The browser shows:

Ein unerwarteter Fehler ist aufgetreten.

Logfiles: pretix.log ERROR 2017-12-10 22:39:54,482 pretix.base.async async Unexpected exception: NotRegistered("'pretix.base.services.export.export'",)

Thanks! ;)

First part of issue for feedback - add context variables to sendmail plugin:

• add placeholders {due_date}, {event}, {order}, {order_date}, {order_url} to message field

Comments/questions:

1. You mentioned

   I'd prefer to use the same syntax there, e.g. {order_url} but the Email Settings has {url} for this specific example so I went with your suggestion, but please let me know and I can change any or all of them.

2. I tried to squash my commits following this but instead of a list of commits I got a noop (or something like that), so I probably did something wrong. :flushed: sorry.... If you want me to try again I will need to clarify the steps first.

3. I'm stuck on the preview part: I'm not sure how to handle the new button action. I was looking into this file, starting on line 342 but I'm not sure how to translate that into this issue. Am I completely off?

Well, I think this is it for now. Thanks!

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 :wink:)

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.

This logs to the database emails sent with sendmail plugin and displays them in the control backend Also adds support to second-level nav to plugins

As I previously mentioned, I'm confused about event-level and order-level logs so I don't know if I am logging/displaying the right thing (probably not). I appreciate feedback. I'm displaying raw (uggly) data but 1- I wasn't sure I had the right thing and 2- I didn't know how to display it prettier.

I didn't remove the code for the new Model either. Let me know if it needs to go.

Secret tickets should not be shown on the event shop by default, but only shown to people who have a secret link specific to that ticket. In order to implement this, the following tasks need to be done

• A secret field containing the secret key should be added to the Item model
• A is_secret boolean field should be added to the Item model
• A checkbox for is_secret should be added to ItemFormGeneral
• The link including the secret should be displayed in the control panel of the product
• The "secret page" should be created. It should check for the secret being correct and then present the user with the option to add the item in various quantities or variations to his/her cart.
• The secret page should somehow pass the secret to add_items_to_cart and this method should check the secret again

I already added a position field to the question options. I never wrote a migration before, please check it.

Next, my guess is that we use Javascript to let the user reorder the options, just as adding options works. The position would be a hidden field in the form. Is there any place in pretix where I can see how to do this?

Starting work on the items API endpoint. Work is far from complete, but I already see one issue that should be discussed. In the current get endpoint variations and addons are embedded. If we maintain that when we implement create and update we need to think carefully about how PUT/PATCH should work:

What is the correct behavior of a partial update with nested items? Well, these are some questions you need to answer:

• When passing a list of nested items where the list does not contain all items that currently exist in my database, should I delete the not present items or just ignore them?
• For the items that are present, should I require complete items or allow updating only some fields?
• If some of the items are invalid but others are valid, should the valid items still be updated, or should the whole request be invalidated?
• If some of the nested items are invalid, should the main object (Invoice) still be updated, or should the whole request be invalidated?

(From reddit discussion)

First decision is if we maintain the current layout where they are embedded, or do we switch to use relations by primary key as in the quotas endpoint? Using primary keys might be easier to implement, but it will be a backwards-incompatible change and as such require a new version of the API.

Any thoughts on this will be greatly appreciated 😃

Updates the requirements on django-compressor to permit the latest version.

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

Updates the requirements on pillow to permit the latest version.

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

This introduces writable API endpoints for creating and updating ticket layouts. It does not yet allow to write the assignment between layouts and products.

Exposing this API in a safe way required formalizing the format we use for layouts for a first time. I have therefore added a JSON schema that can be used to validate the JSON layout and will in the future also help us maintain compatibility between pretix and e.g. pretixPRINT. This schema is used to validate all API endpoints.

I have ran the schema on all ~60k layouts in the pretix.eu database. Almost all of them validate correctly. A very small number (~10) fails due to text areas with fontfamily=null (which is in fact invalid and breaks stuff) or some unsuccessful past exploitation attempts.

I have therefore also added the schema validation to the frontend editor when pasting in custom JSON layouts. This will prevent some human errors in the future. I have not added validation to the server-side code of the backend editor. This means we still can have invalid layouts end up in the database like before, but it allows to fail more softly with the invalid ones we already have. We can always still make this more strict in a separate PR.

Uploading images that are below our 10MB barrier but have millions of pixels can eat up lots of memory, which leads to problems during thumbnail generation. We should already validate for that at upload time.

Updates the requirements on pypdf2 to permit the latest version.

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.