[CRM-15418] Membership tokens not evaluated when used in Scheduled Reminder for membership entity Created: 04/Oct/14  Updated: 17/Jan/17  Resolved: 20/Oct/14

Status: Closed
Project: CiviCRM
Component/s: CiviMember, Core CiviCRM
Affects Version/s: 4.5
Fix Version/s: 4.5.3

Type: Bug Priority: Critical
Reporter: David Greenberg Assignee: Monish Deb
Resolution: Fixed/Completed Votes: 0
Labels: Regression
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Patch
provides patch for CRM-14955 can't add custom defined tokens to cu... Closed
Documentation Required?: None

 Description   

Membership tokens are not evaluated.

The fixes in Utils/Token.php contained in this PR fix the membership tokens issue. HOWEVER, those changes cause hundreds of regressions, hence closed that PR. We'll need to revisit the correct fix, making sure to test the greetingToken functionality and review the PR test build.

Here's an example of one of the regressions
https://test.civicrm.org/job/CiviCRM-Core-PR/767/testReport/junit/%28root%29/api_v3_ActivityContactTest/testCreateActivityContact/

Details:
I used two membership tokens in my scheduled reminder email

{membership.type}

,

{membership.end_date}

... and they are NOT being evaluated (they show up as empty in the output):
---- reminder output ----
Dear ,

Your :: :: (s/b membership type) membership expires on ::
:: (s/b end date).




 Comments   
Comment by David Greenberg [ 20/Oct/14 ]

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

Fixes a regression caused by https://github.com/civicrm/civicrm-core/pull/3616

Comment by Jamie McClelland [ 21/Oct/14 ]

Sorry for the regression. Thanks for making the fix!





[CRM-19886] DB Error on exporting advanced search with "employer of" fields Created: 17/Jan/17  Updated: 17/Jan/17

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

Type: Bug Priority: Important
Reporter: Stephen Forder Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: PNG File Screen Shot 2017-01-17 at 9.00.49 AM.png     PNG File Screen Shot 2017-01-17 at 9.02.13 AM.png     PNG File Screen Shot 2017-01-17 at 9.21.30 AM.png    
Versioning Impact: Patch (backwards-compatible bug fixes)
Documentation Required?: None
Funding Source: Needs Funding
Verified?: No

 Description   

"DB Error: unknown error" occurs when exporting results of advanced search which also includes an Organisation >> "employer of" field.

Works fine with other Organisation fields.






[CRM-18027] No credit card transaction details after 4.7 update Created: 12/Feb/16  Updated: 13/Jan/17  Resolved: 03/Oct/16

Status: Closed
Project: CiviCRM
Component/s: CiviContribute, CiviMember, Core CiviCRM
Affects Version/s: 4.7.1
Fix Version/s: 4.7.13

Type: Bug Priority: Major
Reporter: John L Webster II Assignee: Jitendra Purohit
Resolution: Fixed/Completed Votes: 3
Labels: PatchSubmitted, Regression, payment
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Documentation Required?: None
Funding Source: Core Team Funds

 Description   

Prior to updating to CiviCRM 4.7 our customers received receipts that included:

  • Membership fees with each item listed separately with a description and price.
  • The Transaction number
  • The Billing Name and Address
  • The Credit Card Information (only last four of credit card)

After we installed 4.7 this information stopped displaying on the receipt.

I have reviewed the receipt template. I did not see anything that should change this.

Is there a new setting that I am missing to display the transaction details?

Before

After

Two tickets on Stack Exchange
link_title

link_title

You can update your CiviCRM ticket to tell them that $contributeMode is being set to "notify" for credit card payments, which is why credit card information isn't being printed.



 Comments   
Comment by Joanne Chester [ 15/Mar/16 ]

Just commenting that the upper receipt looks like the online membership receipt in 4.6 and the lower one look like the offline membership receipt.

Comment by Laryn - CEDC.org [ 16/Mar/16 ]

I've had a report of a similar issue, and it looks like (in the case I looked at) profiles that are included on the contribution page are not being included in the emailed receipt after upgrade to 4.7, whereas they were before.

I compared the message template from 4.6 to the template from 4.7 and it doesn't look like there were any substantive changes, so perhaps a variable within the template is being processed differently?

Comment by Coleman Watts [ 23/Apr/16 ]

This sounds like a regression that really should be addressed, but it's not quite "critical" status because there's no data loss or major functionality broken. So the core team will probably take a while to get to is while we focus on the critical stuff. Some community support could help move this forward. If this is important to you, please either submit a pull-request to address the problem (feel free to ask any questions if you get stuck) or provide funding via the paid issue queue.

Comment by John L Webster II [ 02/May/16 ]

You can update your CiviCRM ticket to tell them that $contributeMode is being set to "notify" for credit card payments, which is why credit card information isn't being printed.

Comment by John L Webster II [ 09/May/16 ]

Line items are missing because the current logic searches for 'contribution' line items, but the ones created during sign-up and renewal are stored as 'membership'.

It is possible to restore line items to the receipt by changing line 2587 (in 4.7.6) of civicrm/CRM/Contribute/BAO/Contribution.php from

$lineItem = CRM_Price_BAO_LineItem::getLineItems($this->id, 'contribution', 1);

to

$lineItem = CRM_Price_BAO_LineItem::getLineItemsByContributionID($this->id);

Comment by Eileen McNaughton [ 29/Jun/16 ]

It's probably worth retesting on 4.7.9 rc ( http://dist.civicrm.org/by-date/latest/4.7.9-rc/ ) to see if there are any changes

Comment by Anju [ 17/Aug/16 ]

I am facing same issue with civicrm 4.7.10 and joomla 3.6.2

Comment by P van Kemenade [ 30/Aug/16 ]

Same on 4.7.10, drupal 7.50

I'm trying to update the receipt template to work around this issue.

Can someone explain if it's correct behaviour that $contributeMode is being set to "notify" for credit card payments ? What does it mean ?

Is there a(nother) way to check, in the receipt template, if a payment is not only of $contributeMode 'notify' but specifically a credit card payment ? What other payment types are marked 'notify' ?

Comment by Eileen McNaughton [ 30/Aug/16 ]

I think the contributeMode is a deprecated parameter - we should make sure paymentMethod is assigned

Comment by P van Kemenade [ 31/Aug/16 ]

As far as I can see, the default receipt templates in 4.7.10 don't mention 'paymentMethod' anywhere. Should they ?

Comment by P van Kemenade [ 29/Sep/16 ]

Also, the subject line of the receipt,

{if $is_pay_later}{ts}Invoice{/ts}{else}{ts}Receipt{/ts}{/if} - {$title}

always prints 'Receipt', regardless wether 'pay later' was checked since we upgraded to 4.7.
This appears to be critical in the workflow of my client.

I'm posting it in this bugreport in the idea it should be renamed to 'Contributions - Receipt (on-line) broken on 4.7'. Multiple different bugs have been identified by John L. Webster above, and here is another one, and they all refer to the same system workflow template. It seems to be outdated.

Comment by Monish Deb [ 30/Sep/16 ]

Seems like in 4.7 every related(Event/Membership) contributions are processed through CRM_Contribute_BAO_Contribution::_assignMessageVariablesToTemplate(...) for assigning template variables of contribution receipt . But then its look little weird to assign contributeMode to 'notify' irrespective of the billing mode (as in here CC). So here's the fix https://github.com/civicrm/civicrm-core/pull/9147
Can anyone please verify my patch ?

Also I didn't follow up here that why contributeMode is deprecated because as I can see its usage in every online/offline payment receipt. So is this about what value is assigned to contributeMode ?

Comment by Bruce Wolfe [ 09/Oct/16 ]

Coleman, from a developers perspective I agree with you on priority but receipts must have certain printed information natively for most accounting/bookkeeping departments to accept as "real." What ends up visually to the end-users has to count as somewhat critical. It is inappropriate for online transactions not to include the billing party's information printed on the receipt. I've been ordered by my executive management to use a different donation/event/membership app/service until this is fixed. So, this is a QA "critical" issue from a user perspective.

I am happy to join in on the debugging on this but, warning, I am not a coder.





[CRM-18068] batch member entry: renewal does not extend end date Created: 18/Feb/16  Updated: 13/Jan/17  Resolved: 23/Feb/16

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

Type: Bug Priority: Major
Reporter: Brian Shaughnessy Assignee: Unassigned
Resolution: Duplicate Votes: 1
Labels: Regression
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Duplicate
duplicates CRM-18000 Membership Batch Data Entry: Renewal ... Closed
Documentation Required?: None
Funding Source: Needs Funding

 Description   

when using the batch data entry tool to renew memberships the end date is not extended by the membership period. in other words – the membership is not actually renewed.

this is a regression – it worked properly in 4.6.x.



 Comments   
Comment by Olivier Tétard [ 23/Feb/16 ]

This issue was also reported as CRM-18000.





[CRM-17497] Adding relationship with multi-valued custom field fails Created: 03/Nov/15  Updated: 13/Jan/17  Resolved: 04/Nov/15

Status: Closed
Project: CiviCRM
Component/s: CiviMember
Affects Version/s: 4.6.4
Fix Version/s: 4.6.11

Type: Bug Priority: Critical
Reporter: Ellen Hendricks Assignee: David Greenberg
Resolution: Fixed/Completed Votes: 0
Labels: PatchSubmitted, Regression
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: Text File trace.txt    
Documentation Required?: None
Funding Source: Core Team Funds

 Description   

When adding a relationship that has a custom field set that contains a multi-valued field, such as a checkbox, the throbber spins until the page is refreshed and the error "unknown relationship create error A fatal error was triggered: Cannot recognize for" is displayed.

I traced the problem to a block of code that was added for CRM-15829 in CRM/Contact/BAO/Relationship.php. The failure is on line 1481 (for v4.6.9). I have verified this also fails on the demo site.



 Comments   
Comment by David Greenberg [ 03/Nov/15 ]

Ellen Hendricks Since that block of code handles inherited (related) memberships, it would seem that triggering the bug requires several conditions including an inheritable membership ??

Please provide detailed steps for recreating the bug, along with screenshots. And, if you are able to propose a fix / provide a pull request that would be great.

Thanks!

Comment by Ellen Hendricks [ 03/Nov/15 ]

Steps to recreate:
1) Create a custom field set with a checkbox field.
3) Associate this set with a relationship.
2) Add this relationship to an appropriate contact.

I used the Child of relationship on the demo site.

I did spend several hours trying to fix this issue. I provide support for all our Civi sites and I have other issues to figure out and respond to, unfortunately.

Comment by David Greenberg [ 03/Nov/15 ]

Monish Deb Also getting these notices on next page load after the fatal error:
Notice: Uninitialized string offset: 0 in CRM_Core_DAO::composeQuery() (line 1260 of /Users/dgg/git/crm_v4.6/CRM/Core/DAO.php).
Notice: Uninitialized string offset: 1 in CRM_Core_DAO::composeQuery() (line 1260 of /Users/dgg/git/crm_v4.6/CRM/Core/DAO.php).

Comment by Monish Deb [ 04/Nov/15 ]

Submitted the PR https://github.com/civicrm/civicrm-core/pull/7126

The regression was caused to https://github.com/civicrm/civicrm-core/commit/3421dcee5a6f8d01da9aba73a7365d04e8c98838#diff-7291ff5a1c2bb9adbc0da0929ae9f1d8R1473





[CRM-14536] Free Membership still submits to payment processor Created: 28/Apr/14  Updated: 13/Jan/17  Resolved: 12/Aug/15

Status: Closed
Project: CiviCRM
Component/s: CiviContribute, CiviMember
Affects Version/s: 4.4.4, 4.4.5, 4.6, 4.6.6
Fix Version/s: 4.6.7

Type: Bug Priority: Major
Reporter: Tadpole Collective Assignee: Andrew Hunt
Resolution: Fixed/Completed Votes: 2
Labels: Regression, contribution, membership, price-set
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: JPEG File membership-080615.jpg     PNG File test-free-membership-civi46.png    
Issue Links:
Duplicate
is duplicated by CRM-16852 Combined paid and free membership pri... Closed
Patch
provides patch for CRM-16929 Selecting a zero event price should r... Closed
Documentation Required?: None
Sprint: Sprint 1
Funding Source: Core Team Funds

 Description   

Online contribution page configured for Membership signup and renewal.

  • If page is configured with a FREE membership type (either via quick config on Membership tab OR via a Price Set)
  • AND page uses PayPal Pro OR PayPal Standard

The billing block is hidden when $0 membership is selected (as desired).

However, for both PayPal Std and PayPal Pro - the transaction is submitted to the processor (this is incorrect). The actual behavior and resulting errors are different for Pro and Std.

1. For PP Std - a fatal error is thrown:
./Core/Payment/PayPalImpl.php:748: CRM_Core_Error::fatal(ts('Please set the API URL. Please refer to the documentation for more details'));

2. For PP Pro - the transaction appears to go through to PayPal (since w/ invalid credentials I get the expected error back from PayPal : Error message: 10002: Security error Security header is not valid).

3. If only PayPal Express is configured as the processor for the contribution page, the PayPal Express button (which is the billing block contents) is hidden when user selects a $0 membership. However there is then no submit ("Contribute") button. In this case the dynamic logic needs to SHOW the Contribute button when the PP Express button is hidden.

4. For Authorize.net it sends to the processor and returns an error that there is no card number, effectively the same situation as PP Pro.

5. Using price-set, "Payment Method(s)" options are not hidden when Total Amount is $0.00 unlike quick-config.

6. Using non-required quick-config membership set, payment section is not hidden. (Also ensure the behavior when Contribution other amount is enabled)

---- Original Post ----
On a membership registration page, when a free membership is included the credit card payment details don't get hidden or removed. I am able to click through to next screen without filling out CC details, but it's confusing to potential new members.

The following was added too: templates/CRM/Contribute/Form/Contribution/MembershipBlock.tpl and it works with using the member types but still displays using price-set.

var memAmount = cj('input:radio[name='+priceSetName+']:checked').attr('data-amount');
if ( memAmount == '0.00' )

{ cj('#billing-payment-block').hide(); }

else

{ cj('#billing-payment-block').show(); }

 Comments   
Comment by Allan Chappell [ 28/Apr/14 ]

It looks like this has been thought about some and on the contribution page level and not just memberships.
https://github.com/civicrm/civicrm-core/blob/master/templates/CRM/Contribute/Form/Contribution/Main.tpl#L448-L450

So I think there should be the question of Do we want:

  • the billing portion to never show up if all the items on the page are "Free" and do that on the backend,
  • make the billing section popup at anypoint your amount goes over $0 and initially not show it.
  • some kinda setting to let the admin decide whether we should show the billing section by default.
Comment by Sarah Gladstone [ 04/May/14 ]

This has been fixed for 4.5 using the middle approach: There is JavaScript that runs whenever the page loads and whenever the use changes the priceset. Anytime the Javascript detects a Total Amount greater than 0, it shows the billing block

Comment by David Greenberg [ 04/May/14 ]

Sarah - does that mean the issue is resolved in 4.5 and should be closed ? Thx.

Comment by Kurund Jalmi [ 14/May/14 ]

Sarah, it would be good to handle free events in addition to free memberships.

Comment by Tadpole Collective [ 20/Aug/14 ]

Just tested this on CiviCRM 4.5.beta7 and it's still an issue.

Do we know what needs to get done for this issue to get resolved?

Comment by David Greenberg [ 20/Aug/14 ]

Dana - My understanding from Kurund is that this form needs a significant refactoring to handle the myriad of options and edge cases - so the issue has been pushed to 4.6.

Comment by Tadpole Collective [ 20/Aug/14 ]

Do we have a sense of time to complete (not in terms of version)? We have a few folks complaining about it pretty consistently, so trying to find a way to support the resolution sooner than later.

Comment by Kurund Jalmi [ 20/Aug/14 ]

Yes, form needs significant refactoring to work for various scenarios. It's 2-3 days of work since we need to make sure not breaking stuff and add test(s)

Comment by Dana Skallman [ 18/Sep/14 ]

It would be great if we could get this in 4.5.1. We can help make this happen by supporting at least half of the development time. Does that seem feasible?

Comment by Aaron Cooper [ 23/Jun/15 ]

When I select a membership with a cost of $0 all the payment processors disappear, but I cannot complete the transaction because after the confirmation page, my renewing free members get an error page that indicates CiviCRM is expecting an API URL. Is there a fix that can go in so my free memberships can renew?

I posted the issue on stackexchange with the error page.
http://civicrm.stackexchange.com/questions/2252/error-please-set-the-api-url-when-buying-a-free-membership

Comment by Sanjay Jain [ 05/Aug/15 ]

I am also seeing this problem. But unlike the original bug report the payment options are not showing.

When paypal is active the error is: "Please set the API URL. Please refer to the documentation for details."

When Paypal is not active the error is: "Payment Method is a required field."

Comment by Andrew Hunt [ 06/Aug/15 ]

Increased the severity and updated the affects version. This is a pretty serious regression: organizations with free and paid membership options on the same page suddenly found that people can't sign up. There is no warning about this on upgrade, and end users can't tell it's broken unless they actually try a new membership after upgrading. (Simply viewing the page doesn't give any indication things are wrong.)

Comment by David Greenberg [ 06/Aug/15 ]

Andrew - Based on the history in this issue, it looks like this combination hasn't worked for a long time if ever. You've indicated this is a regression - in what version did this work (e.g. Price Set based online membership signup w/ combination of free and paid membership choices)?

Comment by Sanjay Jain [ 06/Aug/15 ]

Dave - This started happening with a site that was upgraded from 5.8, and we are fairly confident that it was working then

Note - the original issue was that the payment options were showing when the amount was zero. Aaron added to the issue with what seems to be a similar issue, but it may not be exactly the same.

To clarify - the payment options are not showing but the system is looking for a payment processor and will not proceed. A contact is created but no membership is generated.

Comment by David Greenberg [ 06/Aug/15 ]

Sanjay -
1. There is no version 5.8 of CiviCRM, please clarify.

2. There are quite a few possible combinations of configurations that MAY be involved. It's super important that you provide details on the exact configuration(s) that are problematic and the errors / results (e.g. Online Contribution page; Memberships offered via Price Set containing x,y,z options; pay later (yes or no); processor(s) on page = x).

3. Replicating and taking screenshots on 4.6 demo is super helpful.

Comment by Dana Skallman [ 06/Aug/15 ]

screenshot of error for free membership processing

Comment by Dana Skallman [ 06/Aug/15 ]

I did a quick test on 4.6 and I see that with free memberships the billing block now disappears but the error comes up asking for selection of payment gateway. I've attached a screenshot.

Comment by Sanjay Jain [ 06/Aug/15 ]

Dave - Sorry version was 4.5.8 not 5.8

Comment by David Greenberg [ 06/Aug/15 ]

Dana - did you test using a Price Set or just adding membership types to the page from Configure Online Contribution Page => Memberships tab? What payment processor? etc.

Sanjay / Dana - again PLEASE take the few extra minutes needed to provide very specific configuration information when reporting a bug like this.

Comment by Sanjay Jain [ 06/Aug/15 ]

Dave - I was testing on the demo and was not able to replicate the problem. I was using the current Drupal demo - I tested using a price set and then again without a price set.

I saw that the version was 4.6.7 so thought perhaps the issue is fixed..... BUT we then setup a fake payment processor and the problem remains. Using the demo's test processor gives the error shown

Comment by David Greenberg [ 07/Aug/15 ]

Dana, Sanjay, Andrew - Please follow progress on this issue. It will be super important for you to take some time to patch with the PR and test your various scenarios and processors before we merge to 4.6.7.

Comment by Monish Deb [ 07/Aug/15 ]

Submitted the PR https://github.com/civicrm/civicrm-core/pull/6441.

Also fixed a additional bug (updated description with #5) and showing Membership Fee block in Confirm/ThankYou page if fee amount >= $0 . Only remaining stuff is test-case(s) to assert free membership/contribution. Will update the PR soon with that.

Comment by Monish Deb [ 10/Aug/15 ]

Updated the PR with webtest fixes (asserting free memberships are created via online contributions using Dummy, Authnet, Paypal express and Paypal Standard payment processors respectively) and additional fix mentioned in #6.

PR https://github.com/civicrm/civicrm-core/pull/6441 is ready for QA.

Comment by David Greenberg [ 10/Aug/15 ]

Andrew - can you have someone on your team test this out w/ the processor(s) your clients use? Thanks!

Comment by Sanjay Jain [ 10/Aug/15 ]

I tested on a sandbox using a "PayPal - Website Payments Standard" payment processor. I was able to sign-up for a $0 membership.

More testing tomorrow.

Comment by Kevin Cristiano [ 11/Aug/15 ]

Testing on our WP 4.2.x CiviCRM 4.6.6 with this patch applied is positive. No fee events (events with paid and unpaid options) and memberships worked with simple pricing. Still need to test price sets. Will also be testing recurring paid memberships (to ensure no regressions).

Using PayPal - Express and Standard.

Comment by Sanjay Jain [ 11/Aug/15 ]

After applying patch, I can confirm that $0 membership was successful on the following:

Drupal 7.38
CiviCRM 4.6.6
Payment Processors: Authorize.Net & "PayPal - Website Payments Standard"
Priceset = yes

Comment by Daniel Ando Scholnick [ 19/Aug/15 ]

I have this issue on a site I maintain, and would like to test the patch, however, the patch failed on a dry run. If someone can help me resolve that, I'd like to test and provide feedback.

Started seeing this issue on an upgrade from CiviCRM 4.5.4 to 4.6.2 – prior to that, Free Membership signup with this configuration worked.

Drupal 7.38
CiviCRM 4.6.6
Payment Processor: PayPal Payments Pro
Using price set.

Comment by David Greenberg [ 19/Aug/15 ]

Might be best to jump on IRC (#civicrm on freenode.net) to get help applying the patch.

Comment by Daniel Ando Scholnick [ 19/Aug/15 ]

Even better - this fix has been published with 4.6.7, which was just released. As I learned in IRC. Thanks for the suggestion David Greenberg.





[CRM-19078] Cannot search memberships by auto-renew OR not-auto-renew Created: 13/Jul/16  Updated: 13/Jan/17  Resolved: 19/Jul/16

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

Type: Bug Priority: Minor
Reporter: Stoob Assignee: Yashodha Chaku
Resolution: Fixed/Completed Votes: 0
Labels: PatchSubmitted, Regression
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: PNG File after patch.png     PNG File default_none.png     PNG File defaul_o.png     PNG File search-members.png    
Documentation Required?: None
Funding Source: Core Team Funds

 Description   

I would call this a 'regression in functionality' rather than a 'regression bug', but there is no longer a way to search by memberships that are EITHER auto-renew or not.

The attached dropped down 'none' filters out all auto-renew. Selecting one status (and you can only select one status, which is another problem) filters out all not-auto-renew.

The yes/no radio button that allowed you to simply choose is gone.

Suggest both:
1) allowing the box to multi select
2) including "any" an option (which would include any status, including those that are not auto-renew)



 Comments   
Comment by Yashodha Chaku [ 14/Jul/16 ]

I have changed the options from radio to multi-select. I've added any option which will give all auto-renew irrespective of status.
If you want all memberships auto-renew or not, not selecting anything should do it.

PR: https://github.com/civicrm/civicrm-core/pull/8703

Comment by Stoob [ 14/Jul/16 ]

Hi, you said "not selecting anything should do it." Unfortunately that's not the case. "None" is the default when the page loads. This setting filters out any membership that is auto-renewing, it does not include both kinds of memberships.

Comment by Yashodha Chaku [ 15/Jul/16 ]

After applying the patch, the multi-select allows you to not select anything. Please check screenshot

Comment by Stoob [ 18/Jul/16 ]

that looks good thank you

Comment by Yashodha Chaku [ 19/Jul/16 ]

PR https://github.com/civicrm/civicrm-core/pull/8703 has been merged.





[CRM-19848] Membership Since and Start dates not being set when created from an Online Contribution page Created: 09/Jan/17  Updated: 11/Jan/17

Status: Open
Project: CiviCRM
Component/s: CiviCampaign, CiviMember
Affects Version/s: 4.7.11, 4.7.12, 4.7.13, 4.7.14, 4.7.15
Fix Version/s: None

Type: Bug Priority: Trivial
Reporter: Alan Puccinelli Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: JPEG File Screen Shot 2017-01-09 at 2.10.11 PM.jpg    
Versioning Impact: Patch (backwards-compatible bug fixes)
Documentation Required?: None
Funding Source: Needs Funding
Verified?: No

 Description   

When trying to create a membership via an online contribution page the member since and member start dates aren't being set after successful transaction. Contribution and membership record but are missing dates.

Reversion of CRM-17557?

UPDATE 1/11/17:
The issue was that the membership status for New start and end events were set incorrectly to "start date" and not the default "member since" date. Since this was a duplicate of the settings for "Current" status I suspect it was causing a conflict somwhere and therefore assigning no dates whatsoever for Start Date and End Dates on new memberships. Downgraded to trivial as it could still be a potential issue to anyone with an incorrrect Membership Status Rule configuration. Ideally it would be nice if there were some way to validate duplicate Status rules to prevent this type of thing in the future.






[CRM-19855] CiviMember reports display name, not label for Membership Status Created: 11/Jan/17  Updated: 11/Jan/17

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

Type: Bug Priority: Trivial
Reporter: Jon K Goldberg Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Versioning Impact: Patch (backwards-compatible bug fixes)
Documentation Required?: None
Funding Source: Needs Funding
Verified?: Yes

 Description   

The issue is described here:
http://civicrm.stackexchange.com/questions/16601/membership-report-showing-different-status-than-membership-dashboard

To replicate:
Change the labels on built-in membership statuses to something other than the default. Run a Membership Report (Detail, Lapse, or Member Contribution) with the "Status" field selected. You'll see the built-in name, not the user-selected label.

Fixing this for new reports is literally a one-word change in three files. However, in testing, I found that this breaks saved reports, since the serialized "form_values" is storing the field as "name".

A proper fix would require an upgrade script.






Generated at Wed Jan 18 00:53:21 UTC 2017 using JIRA 6.2#6252-sha1:aa343257d4ce030d9cb8c531be520be9fac1c996.