Membership api for v4
Apiv4 doesn't have a membership api yet - mostly because of issues with the membership.create process.
I caught up with @kcristiano this week & we fleshed out what the 3 issues are
- Membership api does financial stuff including creating line items and in some cases creating contribution. I worked through getting rid of one of these bits of magic, converting the back office form to use Order api when setting up a new recurring membership. Getting review on this was slow going so it will take a long time to convert other places. (I have started on the batch membership form & Kevin is going to help with review there).
However, I made a proposal that Kevin agreed with that we simply don't touch ANY of that financial stuff if $params['version'] === 4. The idea is that the handling (which may or may not be right) for apiv3 and for those calls that still call the BAO directly will be unchanged but for v4 callers need to either a) call the order api (which we will fix to call the v4 membership api internally) or b) create their own line items. Note that memberships without contributions actually should have line items according to the model.
Membership date handling for new memberships is in the v3 api (and the form layer). I did a patch for this. https://github.com/civicrm/civicrm-core/pull/20397 - there is a test issue I need to work through and once I've done that I will re-open the PR (I closed it in the meantime as it is not currently reviewable and I don't want reviewers to have to deal with unreviewable PRs)
Membership date handling for renewals. This is the trickiest for me but I think the main issue might be the 'look'
v3 api treats 'num_terms' as a magic parameter and if it is passed it it is treated as 'is_renew' and the dates used are a mixture of any passed in and those calculated for renewal based on num_terms.
I'm inclined to think my issue with this is more about num_terms being too obscure than with the actual logic