Custom invoice payment is carried by _service_paid_by_transaction function

[sbeach92]

Custom invoice payment is carried by modified _service_paid_by_transaction function. Funcion has add_days input variable. Changed basic transaction payment to pass that value allso

Fixes issue of child subscriptions not get paid: https://github.com/TampereHacklab/mulysa/issues/270

If custom invoice service has child services they get paid allso. Payment is carried out at date when last reoccurring custom payment would virtually happen. So If custom invoice payment pays whole year access fee, membership payment would be carried out at last month so membership would last another year.

[sbeach92]

Child subscription date calculation is still a bit problematic as dates are counted from transaction date. If multiple custom invoices are paid child process lefts behind.

[brndd]

The way this works for the yearly membership subscription is bit problematic. Yearly membership shouldn't be a "subscription" in the first place, because it's not something that you can have unpaid dues for -- if you didn't pay your membership fees in 2023, you weren't an active member of the association in 2023, but are free to start paying them again in 2024.

What we would probably need to fix this is a new toggle for services that disables the "negative days" feature for that service. Paying such a service when it's overdue always gives the user the full service's worth of subscription. This could then be used for yearly association membership.

[sbeach92]

The way this works for the yearly membership subscription is bit problematic. Yearly membership shouldn't be a "subscription" in the first place, because it's not something that you can have unpaid dues for -- if you didn't pay your membership fees in 2023, you weren't an active member of the association in 2023, but are free to start paying them again in 2024.

What we would probably need to fix this is a new toggle for services that disables the "negative days" feature for that service. Paying such a service when it's overdue always gives the user the full service's worth of subscription. This could then be used for yearly association membership.

It is bit problematic. But this scales for other services, and custom invoices. One feature is allso that this way does not work as free ticket away from unresolved payments.

[olmari]

@brndd "subscription" is still technical term here.

[brndd]

@brndd "subscription" is still technical term here.

Yearly membership still behaves like a subscription in Mulysa, while at least in Tampere Hacklab rules it's not a subscription, it's for a given year. You either pay your membership for 2024 or you don't, and if you don't, you can pay your membership for 2025 without having to also pay up for 2024.

That's why yearly membership going into the negatives is questionable.

[olmari]

Generally peoples need to resign form membership if they don't want to be member in some given year, so without specifically doing anything going to "minus" is very much proper action, even at Tampere.