Payment Requests

[mark-boute]

Closes #3453 and #941.

Requirements

Implementation

• We will extend the payment models with a PaymentRequest class, this model will store information about the request and the payment itself, it is also a Payable object. Each payed request will become immutable.

• We will add an AdminView which shows all requests, but the default filter only shows 'pending' (unpaid) requests.

• We will add an AdminView for editing pending requests.

• There will be an AdminForm for adding new requests, here you can fill in details, and select any number of PaymentUsers (must be at least 1!) to whom the request apply.

• !TODO think of how we would like to handle late-cancellation fines to happen with the payment-request system

• After creating a new request the user should be notified, we will do this by e-mail and by pushnotification. An admin can send-on-save or do it manually later

Tasklist

• setup model
• write tests for model
• admin views
• admin view tests
• admin form
• admin form tests
• notification time
• email tests
• a connection between fines and service
• connection tests
• (optional) reminder date

Summary

How to test

1. Go to '...'
2. Click on '....'
3. Scroll down to '....'

Notes

• How can we ensure that Users with an expired Membership can still pay (both before the PaymentRequest is created and after if they didn't pay yet but their membership did expire)?

[DeD1rk]

Upon creating a new request the user should be notified, we will do this by e-mail and by pushnotification

This should probably be configurable or a separate manual action. I think it's useful if you can also silenty create a PaymentRequest, send it later, or resend it.
Also, we might want to wait with adding pushnotifications until the app supports paying with a deeplink (very similar to how the app supports paying sales orders).

[DeD1rk]

There should probably be some field to decide (for bookkeeping purposes) whether the payable 'has to be paid sometime'? I don't know enough about that though.

[T8902]

Should we confirm with roel/nick/someone else that knows about bookkeeping what requirements this field should uphold?

[mark-boute]

Upon creating a new request the user should be notified, we will do this by e-mail and by pushnotification

This should probably be configurable or a separate manual action. I think it's useful if you can also silenty create a PaymentRequest, send it later, or resend it. Also, we might want to wait with adding pushnotifications until the app supports paying with a deeplink (very similar to how the app supports paying sales orders).

Changed to: After creating a new request the user should be notified, we will do this by e-mail and by pushnotification. An admin can send-on-save or do it manually later