Problem/Motivation
Perhaps a better way to do this which doesn't require weighting, but this is what i am doing:
I have a bunch of custom fee plugins that i have created. Some of these fees are a fee on the subtotal with some of the other fees included. The only way that i could see to calculate fees on a fee was to know what those fees totaled up to by the "time" the later fee was being calculated. For this i simply use a drupal static var to keep a running total of the fees which "came before". This mostly works, but, as they say, "herein lies the rub".
This has worked, partially by chance and partially by design, because the "earlier" fees are listed in the Fees table "earlier", i.e. they have a lower fee_id.
But as the FeeStorage::loadAvailable() function does not have a sort, it is left up to the db server to sort by its default. We thought this was working, but we have now seen that on our production server (an older version of MariaDB than our staging server) that it does not sort by the order the rows are in the db (fee id) by default (even though the staging server and my local dev setup, do sort by row order).
Sure enough, the way my fee plugins work, this then breaks my fee calculations as it is order processing dependent.
I added this line to the loadAvaialble() method:
->sort('fee_id', 'ASC')
and sure enough, this fixes our fee calculation on our Production server.. mostly.
There is still the issue that we have no control of the order that new fee types are added. A better solution here would be to have a weight column that is used for the sort and have a draggable on the UI for this.
Is is possible I have just done my plugins wrong? Is there some other way to process fees on a fee?
Steps to reproduce
Proposed resolution
Remaining tasks
User interface changes
API changes
Data model changes