An improvement would be to print which backend failed. Also, we shouldn't var_export the whole response object, error code/message would be enough.

In D4033#50378, @vanmeeuwen wrote:

Do shared mail folders and recipients alike have greylisting settings at all?

• Fix test

• Include voucher discount in the signup mandate amount

Use that option also in routes/api.php to remove API end-points for signup. Also, maybe it would be better to use WITH_SIGNUP for consistency with other WITH_* options.

I was thinking that we could do a separate code path for small files that has only one chunk and send Content-Length for them, but it could be done later and I didn't really tested that.

I didn't consider this diff complete. Before we merge this I'd like to know answers to my questions about the findObjectsByRecipientAddress() method:

1. Does it needs an argument to return only these objects that implement senderPolicyFrameworkWhitelist() method?
2. Should it return all objects if e.g. there's an alias to a user and resource at the same time? Right now it's the first found.

Modification of the default theme.json will break some browser tests. We e.g. assert that /support page and faq entries work.

My point was that we're using this in production, so we need to migrate from local to minio or stay at local until we're ready to switch.

You removed some core migration files. That means that there will be references to non-existing files in the database (migrations table). I don't know whether this can cause any issues in the future. Maybe not.

Makes sense, but please note that it will require some configuration when we deploy this change (as the default is 'local').

I'd say it should throw an exception.

This does not cover all use-cases. It works properly only for one sub-level of configuration. I found it simpler and more robust if we instead of:

return [
    'imap' => [
        'digits' => 5,
        'default_folders' => [],
    ],
];

use this syntax:

return [
    'imap.digits' => 5,
    'imap.default_folders' => [],
    // setting only the 'table' option below is not possible with your approach
    'queue.connections.database.table' => 'my_jobs',
];

Replaced by D4136: Signup 'mandate' mode and other improvements

• CS fix

• Merge branch 'master' into dev/signup-mandate-mode
• More tests

• Fix some test regressions
• Fix Stripe checkout

Fixed via D4112: Default sensitivity to 0 (T7121), but indeed we should remove this column. We found the event sensitivity to be useless and misleading.

Nice. We have to silence the linting error: Property App\SharedFolder::$allowed_states is never read, only written.

Thanks. Yeah. I didn't bother with "fixed" mandates for now. Min amount is enough, but we probably will need this too. I'm pretty sure some wording will need to be re-defined.

Merged into dev/signup-mandate-mode. Thanks.

Merged into dev/signup-mandate-mode. Thanks.

• Update some dependencies

• More tests + small fixes

We either use the same set of default folders as in https://git.kolab.org/diffusion/P/browse/master/conf/kolab.conf$65 or make the list empty by default.

I fine with it, but it would make sense to unify the similar code in App\Domain and App\Traits\StatusPropertyTrait.

• Credit_amount for refunds

• Cleanup

• TaxRate -> VatRate
• Fix

• FIx flaky tests

• Payments: tax_rate -> tax_rate_id, base_amount -> credit_amount
• Fix some code errors

As for the need for base_amount... We could get rid of it if we never support change of app.vat.mode on a working system. We could also store the mode instead. Also, having a calculated value that can be "directly" used for balance-related operations is handy. E.g. for Income chart we don't have to calculate the value in a sql query.

• Add some cli commands for tax rates