[CRM-19094] cid=0 membership contribution form can overwrite data of an existing membership Created: 15/Jul/16  Updated: 23/Aug/16  Resolved: 20/Jul/16

Status: Closed
Project: CiviCRM
Component/s: CiviContribute, CiviMember
Affects Version/s: 4.7.9
Fix Version/s: 4.7.10

Type: Bug Priority: Critical
Reporter: Robert J. Lang Assignee: Monish Deb
Resolution: Fixed/Completed Votes: 0
Labels: PatchSubmitted
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Documentation Required?: None
Funding Source: Core Team Funds

 Description   

Creating a new membership using a front-end contribution form with cid=0 can, under some circumstances, overwrite the information of an unrelated membership record if the membership_id of the existing membership record is the same as the contribution_id of the newly-created contribution record.

If there is no existing membership record whose membership_id as the new contribution_id, there is no issue.

I can reproduce this on our test site. After completing the "new membership" form with cid=0, there are three new entries created in the civicrm_membership_log table. Two have the membership_id of the newly-created membership; the third has a different membership_id, which is that of an older existing membership. The data in that membership is overwritten with that of the newly submitted membership. And, in several tests, the overwritten membership_id always matches the contribution_id of the form submission.

There are also two records created in table membership_payment, one with the correct (new) membership, the other with the membership_id (incorrectly) matching the contribution_id.

It's an insidious bug because each occurrence will silently corrupt an existing membership record. But you need to have a membership_id at least as high as the next contribution_id for it to manifest. (We have more memberships than contributions, so it does.)

I think I may have found a logic error that, at least, leads to the duplicate membership_payment entry. In
file: civicrm/CRM/Price/BAO/LineItem.php
function: processPriceSet($entityId, $lineItem, $contributionDetails = NULL, $entityTable = 'civicrm_contribution', $update = FALSE)

This function beginning at line 422 gets called with $entityId set to the contribution_id and $entityTable set to 'civicrm_contribution'.

But down at line 439, we have:

if (!empty($line['membership_type_id']))

{ $line['entity_table'] = 'civicrm_membership'; }

For a membership form, $line['membership_type_id'] is, in fact, non-empty, so $line['entity_table'] does get set to 'civicrm_membership'. But $line['entity_id'] is left at its original value, that of the contribution_id.

So that, at line 454, we have

$lineItems = CRM_Price_BAO_LineItem::create($line);

which, I infer, would create a new entry related to a membership record whose membership_id is equal to the contribution_id.

Sorry I can't pin it down more closely, but I hope that is something to go on. (Note, this is same use case, but different behavior, than https://issues.civicrm.org/jira/browse/CRM-19092.)



 Comments   
Comment by Monish Deb [ 18/Jul/16 ]

Robert J. Lang can you please check my patch https://github.com/civicrm/civicrm-core/pull/8717.patch if it works for you ? Thanks

Comment by Robert J. Lang [ 18/Jul/16 ]

Yes, that fixed it.

Comment by Monish Deb [ 20/Jul/16 ]

Merged PR

Comment by Robert J. Lang [ 23/Aug/16 ]

This bug is marked "fixed" in 4.7.10, but it isn't completely fixed. We installed 4.7.10 and have just detected the case that when a person renews their membership on a contribution page, if there is a membership in the system whose membership ID matches the contribution ID of the renewal, that second membership gets (spuriously) renewed as well. So this issue should still be open.





[CRM-13270] Dates issue in membership type upgrade Created: 21/Aug/13  Updated: 22/Aug/16

Status: Open
Project: CiviCRM
Component/s: CiviMember
Affects Version/s: 4.3.5
Fix Version/s: Unscheduled

Type: Improvement Priority: Major
Reporter: Michelle Johnson Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: membership
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

An organization has two membership types: free and paid. When a member wishes to upgrade from free to paid mid-term (i.e. before renewal date), the only way for the upgraded membership expiration date to be set properly is to create a second membership (pseudo) "organization" and assign the higher level membership type to that "organization." Otherwise the upgraded term is added to the original term, effectively giving the member a new full term plus whatever was left in their original term, but all at the higher level. (So, if someone upgrades on day 1 of a 1-year term, they get two years at the higher membership level, instead of the one to which they are entitled). See later parts of discussion here: http://forum.civicrm.org/index.php/topic,27701.0.html






[CRM-11081] Certain fields are missing the translation dialog on the Membership tab of Contribution pages Created: 17/Oct/12  Updated: 22/Aug/16  Resolved: 22/Aug/16

Status: Closed
Project: CiviCRM
Component/s: CiviMember
Affects Version/s: 4.2.2
Fix Version/s: Unscheduled

Type: Bug Priority: Trivial
Reporter: James Assignee: Unassigned
Resolution: Cannot Reproduce Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Documentation Required?: None
Funding Source: Needs Funding

 Description   

templates/CRM/Member/Form/MembershipBlock.tpl

is missing the I18n dialog for the "new_text" and "renewal_text" fields. These fields are translatable via the database, but they're just missing the dialogs so it can be done via the UI.



 Comments   
Comment by Donald A. Lobo [ 17/Oct/12 ]

james:

can you take a look at the tpl and submit a patch for this. Most likely this is a very trivial patch

thanx

lobo

Comment by Eileen McNaughton [ 22/Aug/16 ]

I'm closing this out based on the age of the ticket. Please re-open if you can replicate on the latest version but so much has changed since then...





[CRM-14416] CiviCRM not changing membership status on time correctly Created: 02/Apr/14  Updated: 22/Aug/16  Resolved: 22/Aug/16

Status: Closed
Project: CiviCRM
Component/s: CiviMember
Affects Version/s: 4.2.15
Fix Version/s: 5.0

Type: Bug Priority: Trivial
Reporter: Seamus Lee Assignee: Unassigned
Resolution: Won't Fix Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Documentation Required?: None
Funding Source: Needs Funding

 Description   

So in the organisation that I am with we have a membership period that runs from 1 July to 30 June. Our members are then grace until 30 September. They are then meant to go expired on 1 April. However due to the code the change membership status happens at 31 March which is over > 9 months after 30 June if you just go by changing the month number. However it is not actually after 9 months.



 Comments   
Comment by Jon Goldberg [ 11/Apr/14 ]

Seamus - rather than setting the membership status change for 9 months past the end date, why not 275 days? This should give the desired outcome.

Since there's a workaround, and fixing this would require an large amount of work for a relatively rare case, I doubt this will get assigned. You should feel free to submit a patch, of course!

Comment by Seamus Lee [ 11/Apr/14 ]

Hi Jon

That is a possible idea, I was also thinking that maybe as a patch idea of adding into the form a set a day number on which it must be x months past or something or if it isn't set then just defaults back to just 9 months past the end date but I understand it may be not get assigned and agree these are edge cases where such a bug does show up and also there is a genuine question as to the functionality of this tool. The organisation I am with is the Australian Greens but more specifically Greens NSW. Tho another one of our states does membership differently to Greens NSW but has also had this same problem arise. (Mainly if a membership ends in February)

Seamus

Comment by Eileen McNaughton [ 11/Apr/14 ]

It does seem like 'end of the month' is a pretty heavy requirement. We have introduced a hook to alter the calculation of membership status which could be used - although this seems more like something you should be able to do without extra (custom) code to me

(the use case we have for the hook is more around different length grace periods for some types)

Comment by Eileen McNaughton [ 22/Aug/16 ]

Seamus - this has been unloved for a long time - I think we can close

Comment by Seamus Lee [ 22/Aug/16 ]

Yeh i think that is fine, i'll just try and attack it either in extension or overnight script





[CRM-13049] Allow user to enter custom contribution fields when using "Record contribution" on backend membership pages Created: 12/Jul/13  Updated: 22/Aug/16  Resolved: 22/Aug/16

Status: Closed
Project: CiviCRM
Component/s: CiviMember
Affects Version/s: 4.3.5
Fix Version/s: Unscheduled

Type: New Feature Priority: Minor
Reporter: Lola Slade Assignee: Unassigned
Resolution: Won't Fix Votes: 1
Labels: contribution, custom-fields, membership
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Documentation Required?: None
Funding Source: Needs Funding

 Description   

CiviCRM should allow the user to enter custom contribution fields (and show them by default) when using "Record contribution" on backend membership forms.

This feature would apply when adding a new membership in "standalone" (not on contact tab) or on contact tab or when renewing a membership - either with or without a credit card. I think this means that three forms are affected.

This allows the user to record the contribution in such a way as to link the contribution to the membership and enter any required custom fields at the same time.



 Comments   
Comment by Coleman Watts [ 28/Jul/15 ]

Lola Slade this should be fairly easy to add thanks to Eileen McNaughton's refactoring of how custom data is loaded on forms.

Comment by Eileen McNaughton [ 22/Aug/16 ]

Hey Lola,

I think this would be a good improvement - but the ticket has been open for 3 years now so lets' close it unless someone gets enthused to work on it





[CRM-11293] Clean up membership receipt template Created: 15/Nov/12  Updated: 22/Aug/16

Status: Open
Project: CiviCRM
Component/s: CiviMember
Affects Version/s: 4.4.0
Fix Version/s: Unscheduled

Type: Improvement Priority: Minor
Reporter: Yashodha Chaku Assignee: Yashodha Chaku
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

Clean up membership receipt template as discussed in CRM-11138

Make sure to fix the following :

Some notes
#1 Use membership array to assign to the tpl (so the first membership can be accessed by $membership.0.membership_name & that works whether it is quick_config or not
#2 Clean up the variables in membership template eg

{if $membership_assign && !$useForMember}

/rename if necessary

It will involve a lot of code cleanup, and template fixes






[CRM-18387] Contribution confirmation page forces custom date fields always to be format yyyy-mm-dd Created: 11/Apr/16  Updated: 22/Aug/16

Status: In Progress
Project: CiviCRM
Component/s: CiviContribute, CiviMember
Affects Version/s: 4.7
Fix Version/s: Unscheduled

Type: Bug Priority: Minor
Reporter: Stoycho Assignee: Dilip Raj Baral
Resolution: Unresolved Votes: 0
Labels: civicontribute, custom-fields, membership, wordpress
Remaining Estimate: 1 day
Time Spent: Not Specified
Original Estimate: 1 day

Attachments: PNG File Untitled.png     PNG File Untitled2.png     PNG File Untitled3.png     PNG File Untitled4.png     PNG File Untitled_13-05-16.png     PNG File Untitled_13-05-16_2.png    
Documentation Required?: None
Funding Source: Needs Funding

 Description   

I have created custom date field with format dd/mm/yyyy and also specified the global date format to be dd/mm/yyyy. I included that field in a Profile and used that profile in a Contribution page. However on the Contribution confirmation page the field is always displayed format yyyy-mm-dd. See the screenshots attached.



 Comments   
Comment by Coleman Watts [ 11/Apr/16 ]

Stoycho would you like to help fund this fix via the paid issue queue?

Comment by Stoycho [ 11/Apr/16 ]

I can't right now mate. Besides this one is "nice to fix".

Comment by Dilip Raj Baral [ 13/May/16 ]

I could't replicate it on 4.7.8. The field format was what it was set. Perhaps it's already fixed.
Pradeep Nayak Joe Murray

Comment by Stoycho [ 13/May/16 ]

Nope,
to replicate - create custom date field, use it in a profile, use that profile in a Contribution page. Also the built in "Birth Date" is always forced to US format on the confirmation page (though the system settings are EU format). See the screenshots below.

P.S.
don't worry too much about this, I'll offer you a patch when i have some time to look at it.

Comment by Eileen McNaughton [ 12/Jun/16 ]

Just removing the fix version as we are no longer setting them until the fix really is happening for that version - please reset when actively worked on





[CRM-16442] Cannot create a fixed annual membership type with no rollover date Created: 02/May/15  Updated: 22/Aug/16

Status: Open
Project: CiviCRM
Component/s: CiviMember
Affects Version/s: 4.6.2
Fix Version/s: Unscheduled

Type: Bug Priority: Minor
Reporter: Graham Mitchell Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Documentation Required?: User and Admin Doc

 Description   

When creating a new membership type, if the period of the membership is, for example, one month, then there is an option to set a rollover day, but it is not a required field. If the period is set at, for example, one year, then the user can set a start date and a rollover date, but the rollover date field appears to be a required field, so it is not possible create an annual membership without setting a rollover date. The user should be able to create a membership type without setting a rollover date.

If the default dates are accepted (i.e. start date Jan 1 and rollover date Dec 31) then a user signing up for membership on Dec 31 gets a membership that runs until Dec 31 the following year, i.e. they get a full year of membership, but if they sign up on Dec 30 they get just one day of membership. This is inconsistent with a use case where the membership type should have no rollover date.

Example: an organisation offers fixed annual membership, with membership fees changing quarterly depending on when in the membership year the new member signs up. So if the fee was reduced by 75% for new members signing up during the last quarter of the year, this should apply consistently to all dates in that final quarter, including the final day of the year. By providing a facility where the rollover date is not required this use case would be satisfied.



 Comments   
Comment by David Greenberg [ 04/May/15 ]

Graham - Not sure I'm understanding the behavior you're expecting for signups in the last few days of the year if 'no rollover date'. It sounds like:

  • signup on Dec 30 - one day membership only, grace or expired on Jan 1
  • signup on Dec 31 - today membership only, grace or expired on Jan 1

Is that the intent?

Comment by Graham Mitchell [ 04/May/15 ]

Hi Dave, thanks for seeking more clarity on this. I think your assumption is correct and is what people would assume to happen in the event that no rollover date was set.

Comment by David Greenberg [ 04/May/15 ]

Valid 'edge case' which has not come up before as far as I know. If there are resources to implement this change we would accept a PR as long as it includes additions to test suite to make sure existing use cases are not affected.





[CRM-17834] incorrect member dates after completing a payment for a future membership Created: 18/Jan/16  Updated: 22/Aug/16

Status: Open
Project: CiviCRM
Component/s: CiviMember
Affects Version/s: 4.6.10, 4.6.11, 4.6.12
Fix Version/s: Unscheduled

Type: Bug Priority: Major
Reporter: Guanhuan Chen Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: PatchSubmitted, membership
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Documentation Required?: None
Funding Source: Needs Funding

 Description   

If a membership is created as following:
Member Start Date: Jan 31st, 2016
Member End Date: Jan 30th, 2017
Contribution Status: Pending

This will create the membership fine with a pending membership status.

Now admin/user comes to complete the payment for the membership today (18th Jan, 2016), the membership details will be updated as following:
Member Start Date: Jan 18th, 2016
Member End Date: Jan 17th, 2017
Contribution Status: New

However, the dates should not change even the payment is completed in advance.

Also the member since date seems cannot be set to any future date which might be a bit of problem.



 Comments   
Comment by Guanhuan Chen [ 25/Jan/16 ]

PR submitted

Comment by Eileen McNaughton [ 25/Jan/16 ]

@colemanw - do we know (or even better have documentation of) the correct behaviour here? I feel like in the past Dave made the call that various things people called bugs were 'by design'

Comment by Coleman Watts [ 26/Jan/16 ]

I could go along with Guanhuan's proposal, but would want to be careful that this fix did not break other spots. I'm thinking of user-facing forms where in fact we do want the day of payment to be the start of membership.

Comment by Eileen McNaughton [ 26/Jan/16 ]

If only there were an advisor who had recently retired but agreed to continue advising & knew all about the history of decisions here

Comment by Guanhuan Chen [ 28/Jan/16 ]

@coleman @elieen

Just to copy my comment from Github to here:

For this fix, in my opinion, the fact that CiviCRM allows users to set a start date for a pending membership naturally leads to the expectation that the start date will take effect in appropriate scenarios.

Please let me know if there is anything I can help to push this forward. Also I am happy to have a discussion around this if needed.

Comment by Joe Murray [ 04/Jul/16 ]

I endorse what Guanhuan Chen says is the expected behaviour conforms to what dgg said is expected behaviour and what I think users want. It should be possible to prepay as well as post-pay (ie pay late) for a rolling membership without changing its start date. However, if the grace period is over and a payment comes in, then the start date should default to that payment date.





[CRM-18503] Membership join_date is incorrectly set by CiviContribute sign-up page Created: 05/May/16  Updated: 22/Aug/16

Status: Open
Project: CiviCRM
Component/s: CiviContribute, CiviMember
Affects Version/s: 4.7.7
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Richard Seabrook Assignee: Jitendra Purohit
Resolution: Unresolved Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Documentation Required?: None
Funding Source: Paid Issue Queue
Payment Status: Estimate Needed

 Description   

Following an upgrade from v4.5.5 to v4.7.3 (and subsequently continuing through v4.7.4, v4.7.6 and v4.7.7), our 'Member Since' or 'join_date' is incorrectly set to be the same as 'start_date' for us this is 2016-01-01.

Prior to this update, 'join_date' was correctly set to today's date at point of joining.

This behaviour is only for signups through a contribution page and does not appear to affect memberships created through the backend UI. Our date format is dd/mm/yyyy and we are using Drupal 7.

Please confirm what information would be useful in troubleshooting. Thank you.



 Comments   
Comment by Richard Seabrook [ 05/May/16 ]

It might also be worth mentioning that we have another date-related issue - we have a custom date field (dd/mm/yyyy format) where the date picker believes that the current date is 01 Jan 2016 as well. We've had to allow future dates as a temporary workaround.

Is there perhaps a global issue with something in CRM_Utils_Date when using dd/mm/yyyy date format?

Comment by Coleman Watts [ 27/May/16 ]

Richard Seabrook check to see if CRM-18660 fixes your custom datepicker issue.

Comment by Jitendra Purohit [ 27/May/16 ]

Richard Seabrook Checked this with multiple scenarios on CiviContribute signup page, but failed to replicate it. The membership join_date, start date are correctly set to today's date unlike the start of the year. Also tested for anonymous, authenticated user signup, taking priceset for membership type, etc but all worked fine for me. Am I missing something ? Are you able to replicate this on dmaster ?

Screenshot from dmaster - http://goo.gl/CAUtn9 (checked with the same date format dd/mm/yyyy). Custom fields too worked fine for me.

Comment by Dan O'Brien [ 08/Jun/16 ]

I have another report of this in the wild using CiviCRM 4.7.7. It's definitely working correctly on 4.6.14. I will see what I can do to narrow down the cause.





[CRM-16704] Contribution Recur ID not stored against membership when renewing Created: 17/Jun/15  Updated: 22/Aug/16

Status: Open
Project: CiviCRM
Component/s: CiviMember
Affects Version/s: 4.4.14
Fix Version/s: Unscheduled

Type: Bug Priority: Minor
Reporter: Eileen McNaughton Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Documentation Required?: None
Funding Source: Needs Funding

 Description   

Given a contact with an existing non-recurring membership, renew the membership using the front end form, selecting recurring renewal.

The value civicrm_membership.contribution_recur_id is not updated.

I have tested this in 4.4.14 & have a patch that works there but have not tested on later versions (& would ideally add a unit test to the api_v3_ContributionPage.submit suite if it is to be fixed in 4.6+)



 Comments   
Comment by Eileen McNaughton [ 17/Jun/15 ]

4.4 patch (in fuzion repo only at this stage) https://github.com/fuzionnz/civicrm-core/commit/3c8380f9e07cc2ec338757e29e3686e676cc9c63

Comment by Coleman Watts [ 02/Aug/15 ]

Eileen McNaughton would you be able to create a PR for this?





[CRM-18242] "email sent" message incorrectly being displayed. Created: 15/Mar/16  Updated: 22/Aug/16

Status: Open
Project: CiviCRM
Component/s: CiviMember
Affects Version/s: 4.6.14
Fix Version/s: None

Type: Bug Priority: Minor
Reporter: kosa Assignee: Saurabh Batra
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Documentation Required?: None
Funding Source: Needs Funding

 Description   

When editing a membership status, even if you don't check the "send
receipt" box, the popup confirmation message after saving says "A
confirmation and receipt has been sent to $address".

however the emial is not sent.

it's now a new issue. it's been there for a while.






[CRM-19091] Membership Status Pending Not Updating to Current (Scheduled Job) Created: 14/Jul/16  Updated: 22/Aug/16  Resolved: 22/Aug/16

Status: Closed
Project: CiviCRM
Component/s: CiviMember
Affects Version/s: 4.7.9
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Lee Gooding Assignee: Unassigned
Resolution: Won't Fix Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Documentation Required?: None
Funding Source: Needs Funding

 Description   

We have several memberships for people that have a Member SInce date and a start date set at a later date. Initially this will set the status to PENDING(Because we have the NEW status disabled). Once the date start date has passed the membership should update to CURRENT(once the scheduled job runs). However, when I run the schedule to update membership status it does not change all the PENDING to CURRENT.

If I go into manually edit the membership for a contact then save it right away it will update the status to CURRENT. This means that my rules are correct.

For example the following membership data has the status set to PENDING and will not update when the scheduled job runs:
Member Since: 6/16/2016
Start Date: 7/1/2016
End Date: 1/1/2017
After further examination of the statuses I have found the behavior related to PENDING to be confusing. Given the following order for status rules:
Current - start/end
Grace - end/end
Expired - end
New - member since/member since
Pending - member since/member since

If I attempt to add a membership at a later date (than today) with NEW status enabled it will create the membership properly. If I disable NEW (so that PENDING will now be the status) and attempt to create the membership it will fail with the following errors:

There is no valid Membership Status available for selected membership dates.
Membership Status Error
Oops, it looks like there is no valid membership status available for the given membership dates. You can Configure Membership Status Rules. OR You can sign up by setting Status Override? to true.

This leads me to believe that there is something wrong with the built-in PENDING status.

*On a side note, the default order for status has NEW as the first rule. When this is the case I believe it never updates to any of the other statuses.



 Comments   
Comment by KarinG [ 15/Jul/16 ]

Have bumped this up to (potentially - if verified) major based on what you describe here - membership status - esp in combination w/ CMS sync is important. How exactly does the first Membership entry get created?

Comment by Lee Gooding [ 15/Jul/16 ]

I just did another test creating a membership directly from the contact. I had to modify the start date in the DB after it was pending so that I could set the start date today (make sense?). I then double checked in the membership area for the contact and it showed pending with the start date for today. That way the schedule would see it as starting today and should update the status to current. I ran it and it does not update it.

Comment by KarinG [ 15/Jul/16 ]

Can you reproduce this on http://dmaster.demo.civicrm.org/ - where you can't make DB updates?

Comment by Lee Gooding [ 17/Jul/16 ]

I have created a membership on the demo site. I just have to wait until tomorrow now to see if it gets updated when I run the job.

I think there is something important to note. I have disabled the NEW status on my CiviCRM setup. By default NEW is the status that will be set when the start date is later than the entry date. PENDING never gets set. By disabling the NEW status, PENDING becomes the status in this case.

I have disabled NEW on the demo site and we will see what happens.

Comment by Lee Gooding [ 18/Jul/16 ]

I just went to check and see if the membership status was updated on the demo site. Unfortunately I have found that there is NO way that I can test this on the demo site. It looks like the DB is reset on a schedule and all the data is cleared to a default (which makes sense in case someone breaks it). At least this is the case with memberships, because it doesn't show for the contact I added it to yesterday.

Comment by KarinG [ 19/Jul/16 ]

It does get wiped (fairly) regularly and unfortunately for you that happened at an inopportune time. Do you want to give it another go? Remember to take lots of screenshots of all your screens; If your edits get wiped again - then I'll try reproduce this for you on a local dmaster.

Comment by Lee Gooding [ 20/Jul/16 ]

It reset everything again.

Here is a link to a doc with screenshots of what I did to set it up for testing: https://docs.google.com/document/d/1QUt6h2mJ0rjINx7WdGzJIErjSa8tu0X24_GUZpb7yH4/edit?usp=sharing

Please note the update to my issue regarding the ordering of the status rules. I noticed this after I had done the initial setup in the document. I'm pretty sure that PENDING and NEW should be below CURRENT, EXPIRED, GRACE (unless I am misunderstanding something).

Comment by KarinG [ 20/Jul/16 ]

Hi Lee - I'll try reproduce your workflow/issue and if I can find a partner to assign to the issue. I believe you are a CiviCRM Member right?

Comment by Lee Gooding [ 20/Jul/16 ]

Yes, I am a member.

Comment by Lee Gooding [ 25/Jul/16 ]

Looks like this may have been an issue for a while: http://civicrm.stackexchange.com/questions/3987/membership-statuses-not-being-updated

Comment by KarinG [ 29/Jul/16 ]

Ok - posting this on the partner list now.

Comment by KarinG [ 31/Jul/16 ]

Hi Lee Gooding - Feedback from the partners list:

  • 'pending' status is set and manipulated by the software for failed transactions (think pending registration, or pending contribution) and thus it is not a best practice to use pending status for a human-based review/trial period for membership.
  • my recommendation would be to create a status specifically for that purpose, such as "in review" or "evaluating" or "trial", whatever the word, and leave pending alone.
  • by removing the 'new' status, and not changing the criteria of 'current' status to start at 'member since', that means the only status available that starts at 'member since' is pending, so they have effectively created a perfect storm of glitchy-ness that could be resolved in another way: setting 'current' to begin at the 'member since' date
Comment by Nicolas Ganivet [ 31/Jul/16 ]

The scheduled job is only made for expiring memberships, not enabling them. This is the way it is coded (see function CRM_Member_BAO_Membership::updarteAllMembershjipStatus()). It should not be changed as well as searching over all memberships and applying status rules would be a lot less efficient than only searching through the current memberships as is done now.

So unfortunately your use case will not be able to be managed through standard CiviCRM processes.

However it would be a very quick custom development to create another scheduled job that goes through your specific Pending status memberships and updates them to Current if needed.

Comment by Nicolas Ganivet [ 31/Jul/16 ]

Karin - your solution will not work per the above. If a membership is not 'is_active' it will not be considered by the cron job (and for good reasons).

Comment by Lee Gooding [ 02/Aug/16 ]

Nicolas,
I was able to take the status NEW and rename it to PENDING ( after renaming PENDING to PENDING-OLD ) and set to be the first rule to run. I then set the Start Event to Member Since, and the End Event to Start Date (-1 day). This will update my new PENDING status when it reaches the end event and set it to CURRENT (after the scheduled job runs).

However, if I attempt to do the same thing with the default PENDING status it does not change the status when the schedule is run. This is confusing and I don't think we should be overriding how a status rule is running if we set it to run a particular way from the GUI. As an end user I would say that it is broken.

Comment by Nicolas Ganivet [ 02/Aug/16 ]

Lee, this is what I was telling you in my first post: the scheduled job only acts on memberships that are active (ie. have Current Membership checked in their properties screen). The former 'New' status has that checkbox checked, so will be transitioned by the scheduled job ; your new 'Pending' status has that checkbox unchecked, so will not be transitioned by the scheduled job.

As said before, this is not a bug, this is by design, and the way it should be. The core logic should not be changed for your very special use case as this will have a huge performance impact for all other CiviCRM installations.

Instead, a new scheduled job should be written that only considers memberships with your new 'Pending' status and changes then to 'New' based on the membership start date. This is a trivial job and your current CiviCRM consultant should be able to do it.

Comment by Lee Gooding [ 02/Aug/16 ]

Nicolas,

Thank you for clarifying. I will look into a custom job, or I'll just use the NEW status.

Correct me if I'm wrong, but if I set the PENDING (built-in) to Member = Yes (which I can do from the UI, even though I can't actually edit properties), then it should be processed because we are now setting it to be a current membership? Or is it ignoring that property? Because when I set PENDING (built-in) to be a 'current' member it does not process that status. If we are ignoring the property, then we should set it to not be editable.

Just to clarify what I am doing. I am basically using the NEW status (for people that sign up) and then going straight to CURRENT on the membership Start Date. It works fine for scheduled jobs. However, this all started because the word 'Pending' made more sense for how we are looking at people that are signed up for membership, but are not active members yet. So I figured we would just use the built-in PENDING status.

This would be a lot easier to explain over chat or phone. I apologize if it is unclear.

Comment by Nicolas Ganivet [ 02/Aug/16 ]

Yes, it will work if you change any membership status to be current (Member = Yes in the statuses list screen) and adjust transition rules accordingly. These 'Pending' memberships will however be counted as active in all reports (ie. they will be counted in your membership dashboard, in membership reports, etc). I don't know if this is an acceptable trade-off for you. If not, you will need to have that custom scheduled job programmed.

Comment by Lee Gooding [ 02/Aug/16 ]

Setting PENDING to current does not seem to have any affect on my end.

Here are my Status Rules (please note I have renamed 'member' to 'service'):

Here are my contact's memberships:

When I run the scheduled job PENDING does not change to Current.

Comment by Eileen McNaughton [ 22/Aug/16 ]

I feel you are creating pain for yourself if you try to use the word Pending to mean something different to what the system expects it to mean. I think your best bet is to come up with another name for the status of 'Paid but not yet engaged' that you are using Pending for.

As Nicolas says there is a secondary meaning of 'Current' - which means 'Should this status be included when reporting on current members'. Sites sometimes also use this to give out access to member content. Editing the membership status will affect this reporting regardless of the name you use - but you do want to retain a status that covers the period 'New' would normally cover that is separate from the reserved Pending status.

I'm going to close this as 'Will not fix' because I don't think there is a bug per se here. Feel free to discuss further here, on chat.civicrm.org or on stack exchange.





[CRM-19150] Preserve contribution when associated membership is deleted (step 1 of 2 | API and BAO) Created: 28/Jul/16  Updated: 22/Aug/16  Resolved: 22/Aug/16

Status: Closed
Project: CiviCRM
Component/s: CiviContribute, CiviCRM API, CiviMember
Affects Version/s: 4.6, 4.7
Fix Version/s: 4.7.11

Type: Improvement Priority: Minor
Reporter: Jose Torres Assignee: Unassigned
Resolution: Fixed/Completed Votes: 0
Labels: PatchSubmitted
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Documentation Required?: None
Funding Source: Contributed Code

 Description   

Currently when a membership is deleted, if there is an associated contribution then the contribution also gets deleted. I would like to see an option to keep the preserve the contrition. I suggest this be completed in two steps: 1) The ability the preserver the contribution through code (API and BAO) and 2) UI change to allow front-end users to check a box to preserve the associated contribution.

https://github.com/civicrm/civicrm-core/pull/8813



 Comments   
Comment by Eileen McNaughton [ 07/Aug/16 ]

Hmm - so if people want to preserve the contribution they need to re-write their code to add the preserve_contribution = 1

I'm find with us signalling a change on this & people having to change their code - as I think the default is dangerous.

But, if people have to change their code anyway then I'd prefer not to support this parameter on the api. Code that wants to do the double-down delete can just use chaining or separate delete calls. Having said that the fact there is a unit test on this swings me in favour of merging.

Can you do a very short blog explaining the change & update https://wiki.civicrm.org/confluence/display/CRMDOC/API+changes

Comment by Jose Torres [ 07/Aug/16 ]

Maybe I wasn't clear, but the default behavior prior to this PR, was to delete the associated contribution. This PR will not change expected ('existing' might be more accurate) behavior for anyone's code, as not including this parameter in the API or BAO will have in the same result always had prior to this PR. What this PR does, is actually allow anyone using the membership delete API and BAO to be less data destructive if the choose to.

Comment by Eileen McNaughton [ 07/Aug/16 ]

I think the existing default is bad enough I'm OK with an announced change that breaks that. I think it people want to throw away payment data they should have to actively choose to do so.





[CRM-19243] Free membership results in two activities and email receipts Created: 18/Aug/16  Updated: 18/Aug/16

Status: Open
Project: CiviCRM
Component/s: CiviMember
Affects Version/s: 4.7.9, 4.7.11
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Anthony Lindsay Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: PNG File CiviCRM_Sandbox_on_Drupal.png    
Documentation Required?: None
Funding Source: Needs Funding

 Description   

Steps to recreate:

  1. create a new membership type
  2. give it a fee of zero
  3. create a membership contribution page
  4. turn off all payment settings
  5. turn on membership settings
  6. allow only the free membership
  7. make membership a requirement for the form
  8. set up a receipt email

Then on completing the contribution form you will receive the receipt email twice and two contribution activities will be recorded on the contact.






Generated at Thu Aug 25 11:24:28 UTC 2016 using JIRA 6.2#6252-sha1:aa343257d4ce030d9cb8c531be520be9fac1c996.