Epic: Refactoring

[cmutel]

Development has gotten a bit hackish as the user stories were not developed enough to have a solid foundation for development. Therefore we need to refactor the app before public deployment.

Separating out Invoice

The biggest change is that logic related to the invoice should be in a separate Invoice (#61) table. We can therefore remove the following from Event:

    currency = models.TextField(null=True, blank=True)  # Show as an input
    payment_deadline_days = models.IntegerField(default=30)
    payment_details = models.TextField(blank=True, default="")

currency needs to be added to RegistrationOption (a single event can have registration in multiple currencies).

In Registration, invoice_no should be replaced with a foreign key. Similarly, paid and paid_date should be removed. extra_invoice_text should be a column (with a different name) in RegistrationOption.

Changing registration options

The table RegistrationOption should only be for registering for an event. A single person can only register once for an event. The column add_on can be removed. Registration can therefore have a foreign key (instead of ManyToMany) to RegistrationOption.

Registration status

Instead of a column active, we should have a choices field (models.TextField(choices=) called status. This can be:

• Application submitted
• Selected
• Wait listed
• Declined
• Registered (payment pending)
• Registered
• Withdrawn

Discounts

This functionality is nice to have, so let's comment it out for now

Membership

The column honorary should be changed to a choices field with possibilities:

• Normal
• Board
• Business
• Honorary

This isn't shown to users when they are registering - board and honorary are created manually, and there is a separate signup for business members.

[lilliputten]

Should we have invoice_no in an old form (year + no) as a PK in the Invoice table? ('In Registration, invoice_no should be replaced with a foreign key').

Should paid and paid_date be moved to Invoice instead of completely removed?

Related question (probably, the most important now): do we have any changes to the man payment procedure: do we still have to change the paid status (in the Invoice table?) on a payment success event?

I don't understand the idea of registration options changes. I'll ask about it later.

Furthermore, I'll need explanations on a status flow (when we should switch to which statuses).

Have seen PR #52: It'd probably be better to generate PDFs on the fly, not to store them as blobs.

What is the template field for there?

[cmutel]

Should paid and paid_date be moved to Invoice instead of completely removed?

Yes, this seems reasonable. These two fields are both needed, but maybe instead of paid we have status with more than on/off choices, for example.

[cmutel]

Have seen PR https://github.com/Depart-de-Sentier/dds_registration/pull/52: It'd probably be better to generate PDFs on the fly, not to store them as blobs.

@jsvgoncalves is a big fan of this idea as well. Let's do that.

What is the template field for there?

Because we can have more than one kind of invoice :)

[cmutel]

Should we have invoice_no in an old form (year + no) as a PK in the Invoice table? ('In Registration, invoice_no should be replaced with a foreign key').

Sure, why not? It must be unique, and doesn't need to be sequential.

[cmutel]

Related question (probably, the most important now): do we have any changes to the man payment procedure: do we still have to change the paid status (in the Invoice table?) on a payment success event?

Yes, we will need to integrate with both Wise and Stripe to automate this - but that is not a requirement for v1 (we need to ship v1 ASAP).

[cmutel]

Furthermore, I'll need explanations on a status flow (when we should switch to which statuses).

Almost all of that is manual, except for payment being made, and even that will be manual for now.

[lilliputten]

Sure, why not? It must be unique, and doesn't need to be sequential.

Probably, we could have the normal auto-incremented integer PK and construct invoice no by adding the year.