Skip to content

GitLab

  • Menu
Projects Groups Snippets
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in
  • C CiviCRM Core
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
  • Issues 1,374
    • Issues 1,374
    • List
    • Boards
    • Service Desk
    • Milestones
  • Deployments
    • Deployments
    • Releases
  • Wiki
    • Wiki
  • Activity
  • Graph
  • Create a new issue
  • Commits
  • Issue Boards
Collapse sidebar
  • Development
  • CiviCRM Core
  • Issues
  • #2902

Closed
Open
Created Oct 09, 2021 by jitendra@jitendraDeveloper

Date fields are empty on memberships (created with pay later OR with an API call)

To replicate -

  • Create a contribution page with Membership + Pay later.
  • Submit the page in live mode.
  • Date fields (join, start & end) are empty for the membership.

Found while writing this test - https://github.com/colemanw/webform_civicrm/pull/622

Probably related to https://github.com/civicrm/civicrm-core/pull/20759 merge where api/v3 code used to calculate the dates for all NEW memberships. https://github.com/civicrm/civicrm-core/pull/20759/files#diff-74f06c64d06b6b6c191ff86ab31113f7198e73c0a1f8c5487116e7b3faef26fcL95

Now, in BAO, the membership date calculation is avoided if skipStatusCal is set in the params. See https://github.com/civicrm/civicrm-core/blob/master/CRM/Member/BAO/Membership.php#L260

I think a test with below API should be able to replicate it in the test

$membership = civicrm_api3('Membership', 'create', [
  'membership_type_id' => "General",
  'contact_id' => 2,
  'status_id' => "Current", (or Pending, New, etc)
  'skipStatusCal' => 1,
]);
// Verify if membership dates are correctly set. Currently, they're not.

I've confirmed that CiviCRM v5.35 sets the date on the above API call, but >5.40 does NOT. Does that seem to be an unintentional change of behavior?

Not sure what should be the desired result - Does the API call need to set start_date separately when skipStatusCal is enabled?

OR

skipStatusCal should only skip the calculation of "status" on the membership and continue to set the dates as it used to do in previous versions?

fyi - @KarinG @eileen

To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information
Assignee
Assign to
Time tracking