Changing time unit for expiration tasks from days to minutes

[EinShoppo]

Q	A
Bug report?	no
Feature request?	yes
BC Break report?	no
RFC?	no

Hi @dpfaffenbauer!

Is there a special reason why the time unit for the expiration tasks for shopping carts, orders and wish lists is days?
We would like to be able to specify these in minutes to be more flexible. In our case, the background is as follows: We have integrated a voucher card provider in our checkout and redeemed vouchers must be released again promptly if any necessary final payment by normal payment method has not been received within X minutes. In this case, the order should be canceled at the same time, so it makes sense to attach to the existing expiration task.
Do you see a problem with changing the time unit from days to minutes? This would be a breaking change (but a very small one), as you would have to multiply your configuration values by 3600 accordingly. Of course you could also make the time unit configurable, but from my point of view the change to minutes would be absolutely sufficient.

Best regards

[dpfaffenbauer]

We never saw a use-case for immediate cancelation of orders. I also think this is a edge case. Two solutions I see:

• We either introduce a new configuration parameter for minutes and be therefore BC save
• You change the behaviour in your project to cancel the order immediately (or within a reasonable time, you don't want to cancel the order when the user is still in the Payment Process)

[EinShoppo]

Hello @dpfaffenbauer,

I have implemented a second parameter for minutes and will make a pull request in the next few days.

Of course we don't want to cancel the order if the customer is still in the payment process. On the other hand, we need to refund vouchers in a reasonable time. This means that if, for example, a customer has not made a payment after 90 minutes, we no longer expect to receive payment, but must release the vouchers so that they can be redeemed again if necessary.

The second parameter is a possibility to define the expiration time more precisely, which is necessary for the above scenario. All without breaking change, so I think this is a good solution.

Best regards