thewca
Dues calculation no longer takes into account the minimum due amount
Describe the bug The dues estimation on WCA when creating a competition no longer takes into account the minimum due amount (for US it is currently $1). This causes the estimation to be wrong:
For context: When you say "no longer", can you confirm that it was correct at some point in the past? Just wondering because we haven't really touched that part of the code in a while.
I am 90% certain it was correct when it was implemented, but not certain.
Hi Jacob, I'm trying to replicate this locally but on my end it took the minimum amount into account:
I imagine the comp is GA Cubers Turkey Gobblers 2022? Sorry if this was creepy but I logged into your dummy account on dev to see where exactly the issue is :P. But here it appeared fine.
Just looked at it. It is correct in production now.
I did repro this by doing the following: Competitions > New competition Fill in country as United States Fill in competitor limit (100) Fill in base registration fee ($5) Notice it does not account for the minimum.
If I had to guess its not taking into account the country when first creating the forum.
I see now. Yeah after hitting "create competition" it becomes correct. I think adding a callback for when country changes can fix this.
Actually it wouldn't be that easy; getting the country band needs the backend function CountryBand.where, so I don't think it can update dynamically with frontend changes. Maybe the fix here is to just add a note saying something along the lines of "hit Update Competition after changing the country" or "Refresh the page after indicating the country to make estimation accurate"?
I think this should be possible without saving. Note that fields like the "Country" dropdown or the "Currency code" selector can all be dynamically read and evaluated through jQuery.
Right now, you rely on the @competition object from Ruby to obtain this information. Of course, you have to save before this value updates. Butt what if you use JS to do something like var country = $('select[name="competition[country]"]').val() (and analogously, var currencyCode = $('select[name="competition[currency_code]"]').val())?
Of course, you cannot take those JS variables and stuff them back into the Ruby CountryBand::BANDS hash at runtime. What you can do however, is to dynamically gather all of the various values (currency code, country, competitor limit, etc.) using jQuery, then AJAX them down to the Ruby backend, have the backend do all of the complex computation logic that you're (partially) doing in JS right now, and only handle the actual display logic back in the JS world.
This would also make the code a whole lot cleaner in terms of "separation of concerns". What do you think?
This sounds like a great solution and I don't have oppositions to it. I'll just need some time to implement it.
One question regarding this is whether a React implementation would change some of the elements described here. For example, we are looking to phase out JQUery. Unless this is a high priority item, perhaps the note to "Refresh the page after indicating the country" is our best interim solution?
It's been a while, so same question as @dunkOnIT. I think I should still proceed with the jQuery approach? It seems that a React implementation of this page would take considerable effort so I imagine the jQuery/AJAX code could last quite a while.
There is absolutely no need to move the entire competition form to React just for the sake of resolving this issue. You can stick with the jQuery implementation but clean it up a little. Think of it as groundwork and preparation for the full React migration :)
As to the specific implementation, I would like all of the calculations be handled by the backend. JavaScript should not make any kind of assumptions or if-else-cases on how or when or why or which fee to calculate. The only job of JS should be to bundle all the necessary information so that Ruby can make a well-informed decision, AJAX that information down to an endpoint, let the endpoint handle all of the business logic, and then (more or less) stupidly dsiplay whatever the endpoint returns, without thinking about how or why that result came to be.
EDIT: My favored approach is pretty much completely described in my previous comment at https://github.com/thewca/worldcubeassociation.org/issues/7143#issuecomment-1232354470