Thanks @bgm
This appears to be a regression in CiviCRM 5.69 upwards. If you create a contribution pages that allows other amounts the amount in that field is recorded in the quantity field of the line item rather than the unit price.
It looks like the quantity and the unit price have been swapped.
The amount is recorded in the quantity field. The unit price is $1.00.
The quantity is 1. The amount is recorded in the unit price field.
Tested in CiviCRM 5.69, 5.70 and 5.73alpha1 (current dmaster). It is an issue in all three versions.
I'm not sure when this stopped working, but think it is quite recent.
Backport to 5.71 in https://github.com/civicrm/civicrm-core/pull/29787
https://github.com/civicrm/civicrm-core/pull/29717 has been merged so the fix will be included in 5.72.
New PR created for 5.71: https://github.com/civicrm/civicrm-core/pull/29787
I've tested the above and it does indeed fix this issue.
I've created two backport PRs for this:
Looking back at the git history, I think this issue was introduced in this PR, which was included in 5.69:
https://github.com/civicrm/civicrm-core/pull/28294
The fix appears to be to change line 1005 in CRM/Financial/BAO/Order.php
:
- $lineItem['unit_price'] = $lineItem['line_total'] / $lineItem['qty'];
+ $lineItem['qty'] = 1;
+ $lineItem['unit_price'] = $lineItem['line_total'];
I'm going to check this.
I haven't tested this yet, but https://github.com/civicrm/civicrm-core/pull/29717 may fix this issue.
This appears to be a regression in CiviCRM 5.69 upwards. If you create a contribution pages that allows other amounts the amount in that field is recorded in the quantity field of the line item rather than the unit price.
It looks like the quantity and the unit price have been swapped.
The amount is recorded in the quantity field. The unit price is $1.00.
The quantity is 1. The amount is recorded in the unit price field.
Tested in CiviCRM 5.69, 5.70 and 5.73alpha1 (current dmaster). It is an issue in all three versions.
I'm not sure when this stopped working, but think it is quite recent.
@dmunio Thanks for looking in to this. Are you able to make a merge request with your patch so we can see what changes you've made and hopefully get this merged into the extension?
I've come across the same issue on a client site. This patch fixes it.
Thanks for making these changes. In general I agree with the aim of reducing clutter and improving the user experience. However, I think that some of the changes have had a negative impact on usability and may need to be reconsidered, in particular the 'Save and Done' button.
You've asked above:
what does "Done" even mean?
What it means for the user, when editing a multi-page form, is that they have made all of the changes that they want to make and the form can be closed.
For a single page form it is fine to have a single Save button. This saves all of the changes and closes the form. Alternatively you can click Cancel to discard all of the changes and close the form.
With a multi-page form there were four possible routes that were represented by the four buttons:
By reducing this to two buttons (Save and Cancel) we are making it hard for the user to complete the form.
Consider the following steps the user needs to take to create a new event:
What does the user do now? They have finished editing the event. They have clicked Save, the details are saved, but the form is still open. What should they click?
Well, actually the simplest thing for them to click would be Cancel because they have already saved the details and this would close the form and take them back to the manage events page. But from a user's perspective Cancel is the wrong button to press. It means that you want to discard all of your changes, which is the opposite of what the user wants to do. We shouldn't expect the user to do this but we aren't really leaving them with any other sensible options. Another option would be to use the menu to navigate to the Manage Events screen or another page. Alternatively, they could click on the back button in the browser. Neither of these are good options from a user experience perspective.
Note that by removing the 'Save and Next' button we are making it slightly more work for the user to move from one page to the next - this takes two clicks rather than one. I don't have such strong feelings about this but noting that it is making the user experience slightly worse.
We've just upgraded a client site to CiviCRM 5.70 and have had some feedback from a member of staff on these changes:
I have gone to duplicate an event and the save and done button is no longer appearing as an option.
I really liked the feature as I felt it acted as a final check that I had completed all sections of the event setup.
I'm not saying that we should revert all of the changes made, but I do think we need to address the case of a user editing a multi-page form. Afraid I don't have a solution, but perhaps we should look at how other software handles this use case.
wmortada (efc315c1) at 07 Mar 15:22
MR submitted: !377 (merged)
Closes #288.
wmortada (efc315c1) at 07 Mar 13:36
Improve steps for switching to InnoDB
The current documentation is confusing and out of date. I've just switched a site to use InnoDB for logging and it took me a while to work out what to do. Once I had worked it out, it was pretty simple so to avoid others having the same issue, I've updated the documentation.
The documentation was updated in 64938bf7 following the core changes in https://github.com/civicrm/civicrm-core/pull/14256
However the section on 'Swapping over to INNODB for storage format' wasn't updated and is now out of date. There is no longer any need to install a separate extension. All you need to do is run the core API call:
cv api System.updatelogtables forceEngineMigration=1
I'll submit an MR to fix this.
@JKingsnorth thanks for looking in to this. We're in the process of upgrading client sites so will update here if this is still an issue on the latest versions of CiviCRM and Stripe.
I think it makes sense to keep the tarball simple so that it is easy to install and upgrade. From that point of view, @totten, I think your layout makes sense.
I also think composer
significantly increases the barrier to entry so I would like to see a non-composer
option. Happy to see composer
being the recommended option so long as there is also an option for people that don't want to or aren't able to use it.
For reference the above PR was merged into CiviCRM 5.70.
There was also a backport for CiviCRM 5.69: https://github.com/civicrm/civicrm-core/pull/29084
Thanks @kurund!
@eileen I realise that I didn't reply back in September. I must have overlooked this. Apologies for that.
For reference the merged PR is: https://github.com/civicrm/civicrm-core/pull/29358
This will be included in CiviCRM 5.71.