Fix #7 - Allow overwrite mollie api key and methods on organizer level.

[raphaelm]

Thank you very much for the work you put into this.

However (and it hurts to say this), I do not think I want to merge this. This kinda rips the mollie settings out of the general framework of payment provider settings and makes mollie work different than all others. This has a couple of downsides:

• Your code duplicates every mollie-related setting to multiple different places, increasing maintainance overhead e.g. if mollie gains a new payment method and increasing the likelyhood of errors.

• This will cause confusion as to why this is possible for Mollie but not for every other payment method.

Allowing to set event settings on organizer level is something we want to have in pretix for a very very long time (although usually as a way to set a default, not as a way to disable them on event level). Most of our users do not need to have diffferent payment settings per event, often it is even a problem that they do. However, some need that flexibility.

While setting things on organizer level is trivially possible with our settings data store hierarkey, it is tremendously hard to come up with a user interface that is useful and at the same time communicates the logic effectively to non-technical users. You can see an example of one of our approaches to try this in the shop design settings, where colors/fonts can fall back to organizer level. As you can see, it requires lots of text to explain and it requires to split settings into different chunks that can only be overridden blockwise (granted, this would be easier for payment providers).

I can see a future in which we implement the full payment settings dialog thing on organizer level as well and enable it on event level only if the user really needs it. We could even tie this to a new permission. But I do not want to solve this – im my view very fundamental – problem on a per-payment-provider basis.

[MaicoTimmerman]

Thanks for your response. I share your view on the maintainability of the settings of organizers/events and understand your decision of not merging the PR. For the coming future, I'll be running a fork of this plugin in our pretix instance to be able to protect our Mollie API secrets.

I'd be interested to work towards deprecating the fork in the future, which means creating a fundamental solution for the problem you described. This however that would require quite some architectural changes, for which I currently do not a have clear approach. How, in your opinion, could the project proceed to get these changes done?

[raphaelm]

How, in your opinion, could the project proceed to get these changes done?

If I knew exactly what to do here, I might have already done it :)

Here's the part that sounds simple:

• We could add a menu item "Settings > Payment" to the organizer section which looks just like the event settings and automatically collects the settings from all the payment providers.
• This could work directly on organizer.settings, which automatically is a default for event.settings
• We could just disable the payment settings on event level if they are used on organizer level, or, like in the design settings, allow to "detach" an event by copying over all values to event.settings (this could then be disabled in some way for your usecase)

Here's why it is hard:

• If we don't want to show all payment providers, we need to create a concept of plugins on organizer level. What does it mean if a plugin is enabled on organizer level but not on event level? A possible, backwards-compatible concept could be that if a plugin is enabled on organizer level it's enabled for all events, while events can enable additional plugins (but not disable ones that are enabled on organizer level)

• This requires us to change how EventPluginSignal works

• This requires us to be able to initialize a payment provider class without an event, breaking assumptions in possible tens of settings_form_fields implementations

All of this would be useful! But all of this will also make both code and UI more complicated.

Another thought: Completely unrelated, but maybe also a solution if your primary concern is protecting the API key: It might be useful to switch all API keys to a form field that does not show the stored value (like the password field in the SMTP settings but with a better UX to show whether it is filled or not). What do you think about that?