Hide pricesetTotal #16
Conversation
|
Yeah, I struggle with the magic js that updates the total, frequently. I guess hiding it would be the path of least resistance, though not optimal. I'm glad that actual amount charged is correct! The issue is that the interface is hiding some of the fields and in theory also setting their values to 0. Based on that the amount charged is correct, that seems to be successful, so I guess the question is why the js total showing isn't correct. Here's an example https://secure.fairvote.ca/en/civicrm/contribute/transact?reset=1&id=67 It's actually not using this extension, but it's using the original custom extension that I wrote on which I based the code I added to this extension. I notice with it, it works with the radio options, but not the "other" text field. Is that the same experience as you're seeing, or is it the radio button options as well? Do you have a url where I can look at your example? FWIW, the civi core js code that's generating the total is in the page source, at the comment "// Recalculate the total fees based on user selection", and the js code that this extension is providing is here: |
|
Looking at Calculate.tpl, maybe the issue is that you need a click to trigger the recalculation, but your js un-selects the option without any kind of click happening that would trigger the recalculation. But I'm not clear on the details. For our use (which is similar to the fairvote one), I'm happy enough just hiding the total. Since you can only select one option at a time and can't have a radio option amount and an other amount, it seems kind of redundant here. |
|
Actually, the fairvote one works and ours doesn't, even through they look pretty similar. So I'll try the older code on ours and report back. |
|
Tried the old code on ours and the result is the same, adds up both selections. So something is different either in core or the extension between ours and fairvote. Bit of a mystery. |
|
Great, looking at your example (and unhiding the div with the console), I think what I see is that when you switch from recurring to non-recurring and back again, it copies the selected radio amount to the new radio group, which is nice, but fails to remove it from the old one, ie. I think this extension is actually just about perfect except for that error. On the other hand, I don't disagree that hiding the calculated amount makes a lot of sense for this kind of selection, so I'm kind of tempted to:
|
|
That would be great!
…On Wed, May 24, 2023 at 12:07 PM Alan Dixon ***@***.***> wrote:
Great, looking at your example (and unhiding the div with the console), I
think what I see is that when you switch from recurring to non-recurring
and back again, it copies the selected radio amount to the new radio group,
which is nice, but fails to remove it from the old one, ie. I think this
extension is actually just about perfect except for that error.
On the other hand, I don't disagree that hiding the calculated amount
makes a lot of sense for this kind of selection, so I'm kind of tempted to:
1. Try and fix the remaining issue w/ the js
2. Provide the option to hide the calculated amount
—
Reply to this email directly, view it on GitHub
<#16 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AGCV35AU2TIJ2G22ZRBMWKLXHZE7PANCNFSM6AAAAAAYMNJI6A>
.
You are receiving this because you authored the thread.Message ID:
***@***.***>
|
This div is showing an incorrect amount if you select a one-time option and then switch over to the recurring tab or if you select an option and then an other amount after (it just keeps adding). The actual charged amount is correct and I don't really think this calculated field is needed, so I've just hidden it. But maybe you want to fix it instead?