Answers.Body: <p>This problem was seen on one of our sites and the issue was in the status rule page where Pending is selected as <code>Member</code> = <code>Yes</code>.</p>
  <p>Pending is a reserved status that defaults to Current Member = No. Civi doesn't allow you to edit this status via UI but i see inline edit still works on these statuses. This is clearly a bug in core.</p>
  <p><a href="https://i.sstatic.net/0x76e.png" rel="nofollow noreferrer"><img src="https://i.sstatic.net/0x76e.png" alt="enter image description here" /></a></p>
  <p>So i think it was unintentionally updated to Yes on your site since i see the same case on your attached screenshot.</p>
  <p>Reverting this value back to <code>No</code> fixes the problem with the dates.</p>
  
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2021-05-20T02:53:51.667Z
Answers.Text: This seems to be the case for me! I don't have inline editing. Any idea how I can fix this? Should I update it in MySQL manually?
Answers.UserDisplayName: Christia
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2021-05-20T09:07:11.697Z
Answers.Text: yes, if you have access. Resetting it back to No should fix the problem.
Answers.UserDisplayName: jitendra - fuzion
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2021-06-29T20:00:40.140Z
Answers.Text: Do I need to do this manually in the database? The controls aren't available in this version.
Answers.UserDisplayName: Christia
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2022-03-09T22:05:34.187Z
Answers.Text: Oh right, thanks! (I don't seem to have been notified about this answer :( I'd forgotten all about it until I happened upon it just now. I've changed this setting, though I do remember deliberately changing it since we want to count pending as a member (even if for example the direct debit hasn't quite completed).
Answers.UserDisplayName: dom
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2021-04-27T06:46:51.973Z
Answers.LastActivityDate: 2021-04-27T06:46:51.973Z
Answers.UserDisplayName: jitendra - fuzion
Body: <p>I've noticed that ever since we started taking online contributions (last summer) new members have been getting created with null start date and &quot;member since&quot; date. Offline memberships (created via the backend) work fine, and the membership statuses all seem to work correctly otherwise. The end date is also set correctly. I'm using both GoCardless and Stripe payment processors and the problem appears with both of them.</p>
  <p><a href="https://i.sstatic.net/1Ely8.png" rel="nofollow noreferrer"><img src="https://i.sstatic.net/1Ely8.png" alt="enter image description here" /></a></p>
  <p>The practical upshot of this is that these members are not being counted in the membership summary dashboard - this is probably also a bug - either the schema should enforce these values not being null, or the dates shouldn't be used to calculate a &quot;current&quot; member.</p>
  <p>In case it's relevant, here are the membership status rules:</p>
  <p><a href="https://i.sstatic.net/bvBMs.png" rel="nofollow noreferrer"><img src="https://i.sstatic.net/bvBMs.png" alt="enter image description here" /></a></p>
  <p>Some other details:</p>
  <ul>
  <li>the memberships are rolling</li>
  <li>hosted on Drupal 7 and MySQL</li>
  <li>running CiviCRM 5.34.0, but problem dates back to at least 5.28.1, the version running when the earliest membership of this type was created.</li>
  <li>Detailed logging is enabled, and there's no evidence of the dates being set and cleared.</li>
  </ul>
  <p>There are similar issues described at <a href="https://civicrm.stackexchange.com/questions/27125/start-member-since-dates-not-being-set-since-upgrade-to-5-3-2">Start/member since dates not being set since upgrade to 5.3.2</a> and <a href="https://civicrm.stackexchange.com/questions/21727/member-since-and-start-date-arent-being-recorded-in-membership-details">Member Since and Start Date aren&#39;t being recorded in membership details</a> but there is no resolution of either of those and they're both a few years old, so I figured a fresh report would not be a bad thing.</p>
  <p>Edit to add screenshots of the contribution page (membership and profile sections):</p>
  <p><a href="https://i.sstatic.net/nbvFh.png" rel="nofollow noreferrer"><img src="https://i.sstatic.net/nbvFh.png" alt="enter image description here" /></a></p>
  <p><a href="https://i.sstatic.net/6VmBG.png" rel="nofollow noreferrer"><img src="https://i.sstatic.net/6VmBG.png" alt="enter image description here" /></a></p>
  <p>Edit to add:</p>
  <p>Some experiments I tried to rule out various causes</p>
  <ul>
  <li>The same thing happens with a dummy provider or a free membership.</li>
  <li>Pay later puts the membership into pending state, with no dates at all (based on comments this also seems unexpected</li>
  <li>The same thing happens on a clone of the live site with all extensions disabled</li>
  <li>The same test installation with a completely fresh install and the demo contribution form works as expected, populating all the dates correctly.</li>
  </ul>
  <p>So have pinned it down to something in our live database at least, rather than anything basic with the environment or code deployment, but I've pored over the differences in settings and contribution forms from database dumps and found nothing promising.</p>
  
Comments.ContentLicense: CC BY-SA 4.0
Comments.CreationDate: 2021-02-20T21:50:02.967Z
Comments.Text: How are the online memberships happening? Drupal Webform of CiviCRM Contribution pages?
Comments.UserDisplayName: Parvez Saleh
Comments.ContentLicense: CC BY-SA 4.0
Comments.CreationDate: 2021-02-20T22:47:31.293Z
Comments.Text: Contribution pages - I added a couple of screenshots.
Comments.UserDisplayName: dom
Comments.ContentLicense: CC BY-SA 4.0
Comments.CreationDate: 2021-02-21T10:40:02.110Z
Comments.Text: Thats strange, we have a fair few membership organisations running online contributions pages for joining and not see this before. I would probably try a few experiments - allowing pay later perhaps, trying dummy payment processor and maybe try also a free membership. Would try to eliminate payment processors as possible sources. Alternatively try disabling all extensions on a test site and see if that leads to an answer.
Comments.UserDisplayName: Parvez Saleh
Comments.ContentLicense: CC BY-SA 4.0
Comments.CreationDate: 2021-02-21T19:26:41.563Z
Comments.Text: No luck with the first set of experiments - the same thing happens with a dummy provider or a free membership. Pay later puts the membership into pending state, with no dates at all, which seem fair. I'll set up a test instance during the week.
Comments.UserDisplayName: dom
Comments.ContentLicense: CC BY-SA 4.0
Comments.CreationDate: 2021-02-21T20:11:39.053Z
Comments.Text: Pay later should default the dates, even if the membership is in a pending state. I would try the test environment without extensions. Feels like something is interfering with Civi's default behaviour.
Comments.UserDisplayName: Parvez Saleh
Comments.ContentLicense: CC BY-SA 4.0
Comments.CreationDate: 2021-02-21T20:57:25.660Z
Comments.Text: also worth confirming that it works as expected on dmaster.demo or one of the other sites
Comments.UserDisplayName: petednz - fuzion
Comments.ContentLicense: CC BY-SA 4.0
Comments.CreationDate: 2021-02-25T23:06:02.937Z
Comments.Text: I've tested on a clone of the live site, same problem, even with all extensions disabled. Same test installation with a completely fresh install and the demo contribution form works as expected, populating all the dates correctly. So have pinned it down to something in our live database at least, rather than anything basic with the environment or code deployment.
Comments.UserDisplayName: dom
Comments.ContentLicense: CC BY-SA 4.0
Comments.CreationDate: 2021-02-27T00:23:09.997Z
Comments.Text: Pored through the database looking for relevant differences in the settings/contribution forms etc, found nothing.
Comments.UserDisplayName: dom
Comments.ContentLicense: CC BY-SA 4.0
Comments.CreationDate: 2021-03-01T01:14:26.787Z
Comments.Text: just occured to me you have changed the order of your Status rules by dragging Pending to the top. wonder if this might be an issue. compare it to https://dmaster.demo.civicrm.org/civicrm/admin/member/membershipStatus?reset=1
Comments.UserDisplayName: petednz - fuzion
Comments.ContentLicense: CC BY-SA 4.0
Comments.CreationDate: 2021-03-01T22:23:25.563Z
Comments.Text: @petednz-fuzion no, I tried resetting the order to the out of the box order and that didn't make a difference.
Comments.UserDisplayName: dom
Tags: <civimember><contribution-page>
Title: Membership start date and "member since" date not set with online contributions
ThreadText: # Membership start date and "member since" date not set with online contributions
  
  (Asked by: username_0 on 2021-02-20)
  
  I've noticed that ever since we started taking online contributions (last summer) new members have been getting created with null start date and "member since" date. Offline memberships (created via the backend) work fine, and the membership statuses all seem to work correctly otherwise. The end date is also set correctly. I'm using both GoCardless and Stripe payment processors and the problem appears with both of them.
  
  [![enter image description here](https://i.sstatic.net/1Ely8.png)](https://i.sstatic.net/1Ely8.png)
  
  The practical upshot of this is that these members are not being counted in the membership summary dashboard - this is probably also a bug - either the schema should enforce these values not being null, or the dates shouldn't be used to calculate a "current" member.
  
  In case it's relevant, here are the membership status rules:
  
  [![enter image description here](https://i.sstatic.net/bvBMs.png)](https://i.sstatic.net/bvBMs.png)
  
  Some other details:
  
  * the memberships are rolling
  * hosted on Drupal 7 and MySQL
  * running CiviCRM 5.34.0, but problem dates back to at least 5.28.1, the version running when the earliest membership of this type was created.
  * Detailed logging is enabled, and there's no evidence of the dates being set and cleared.
  
  There are similar issues described at [Start/member since dates not being set since upgrade to 5.3.2](https://civicrm.stackexchange.com/questions/27125/start-member-since-dates-not-being-set-since-upgrade-to-5-3-2) and [Member Since and Start Date aren't being recorded in membership details](https://civicrm.stackexchange.com/questions/21727/member-since-and-start-date-arent-being-recorded-in-membership-details) but there is no resolution of either of those and they're both a few years old, so I figured a fresh report would not be a bad thing.
  
  Edit to add screenshots of the contribution page (membership and profile sections):
  
  [![enter image description here](https://i.sstatic.net/nbvFh.png)](https://i.sstatic.net/nbvFh.png)
  
  [![enter image description here](https://i.sstatic.net/6VmBG.png)](https://i.sstatic.net/6VmBG.png)
  
  Edit to add:
  
  Some experiments I tried to rule out various causes
  
  * The same thing happens with a dummy provider or a free membership.
  * Pay later puts the membership into pending state, with no dates at all (based on comments this also seems unexpected
  * The same thing happens on a clone of the live site with all extensions disabled
  * The same test installation with a completely fresh install and the demo contribution form works as expected, populating all the dates correctly.
  
  So have pinned it down to something in our live database at least, rather than anything basic with the environment or code deployment, but I've pored over the differences in settings and contribution forms from database dumps and found nothing promising.
  
  **Tags:** civimember, contribution-page
  
  > **Comments:**
  > **username_1**: How are the online memberships happening? Drupal Webform of CiviCRM Contribution pages?  
  > **username_0**: Contribution pages - I added a couple of screenshots.  
  > **username_1**: Thats strange, we have a fair few membership organisations running online contributions pages for joining and not see this before. I would probably try a few experiments - allowing pay later perhaps, trying dummy payment processor and maybe try also a free membership. Would try to eliminate payment processors as possible sources. Alternatively try disabling all extensions on a test site and see if that leads to an answer.  
  > **username_0**: No luck with the first set of experiments - the same thing happens with a dummy provider or a free membership. Pay later puts the membership into pending state, with no dates at all, which seem fair. I'll set up a test instance during the week.  
  > **username_1**: Pay later should default the dates, even if the membership is in a pending state. I would try the test environment without extensions. Feels like something is interfering with Civi's default behaviour.  
  > **username_2**: also worth confirming that it works as expected on dmaster.demo or one of the other sites  
  > **username_0**: I've tested on a clone of the live site, same problem, even with all extensions disabled. Same test installation with a completely fresh install and the demo contribution form works as expected, populating all the dates correctly. So have pinned it down to something in our live database at least, rather than anything basic with the environment or code deployment.  
  > **username_0**: Pored through the database looking for relevant differences in the settings/contribution forms etc, found nothing.  
  > **username_2**: just occured to me you have changed the order of your Status rules by dragging Pending to the top. wonder if this might be an issue. compare it to https://dmaster.demo.civicrm.org/civicrm/admin/member/membershipStatus?reset=1  
  > **username_0**: @username_2 no, I tried resetting the order to the out of the box order and that didn't make a difference.  
  
  ---
  
  ## 1 answers
  
  ### Answer by username_3 on 2021-04-27. Score: 2
  
  This problem was seen on one of our sites and the issue was in the status rule page where Pending is selected as `Member` = `Yes`.
  
  Pending is a reserved status that defaults to Current Member = No. Civi doesn't allow you to edit this status via UI but i see inline edit still works on these statuses. This is clearly a bug in core.
  
  [![enter image description here](https://i.sstatic.net/0x76e.png)](https://i.sstatic.net/0x76e.png)
  
  So i think it was unintentionally updated to Yes on your site since i see the same case on your attached screenshot.
  
  Reverting this value back to `No` fixes the problem with the dates.
  
  > **Comments:**
  > **username_4**: This seems to be the case for me! I don't have inline editing. Any idea how I can fix this? Should I update it in MySQL manually?  
  > **username_3**: yes, if you have access. Resetting it back to No should fix the problem.  
  > **username_4**: Do I need to do this manually in the database? The controls aren't available in this version.  
  > **username_0**: Oh right, thanks! (I don't seem to have been notified about this answer :( I'd forgotten all about it until I happened upon it just now. I've changed this setting, though I do remember deliberately changing it since we want to count pending as a member (even if for example the direct debit hasn't quite completed).  
  
  ---
  
  