- we are using OR between two queries here: 53ec6621bc/app/services/search_orders.rb (L31-L32)
- so to make it compatible with this, had to revert
Throws following error:
Relation passed to #or must be structurally compatible. Incompatible values: [:left_outer_joins]
A fee can be associated to both the incoming and outgoing exchange, the
previous logic did not account for that, resulting in the fee not being
correctly removed.
Now the delete logic also check for the metadata enterprise role to see
if any additional fee need to be removed.
We now update or create line item fees instead of deleting them and
recreating them. This is to cover the case when a product has been
removed from an Order Cycle but we want to keep the fee already applied
on existing order. This was an issue only if the existing order got
updated after the product was removed.
The string '< Hidden >' was agreed on as a good default, so we will use the hidden_field key.
I also moved the definition in en.yml up to the more general area at the start of admin.reports section (before it was hidden between report-specific keys.
when permitted.
The MaskDataService is used by the report framework, so this should affect all reports. It would be nice to test all reports, but I figured it wasn't worth it (already we only test one report for masking names).
I was hoping to reduce the query count but it stayed the same. In fact,
I'm expecting the query count to be higher with this version. The
DfcCatalogImporter queries all variants and links at once while the OC
job is not pre-loading the variants at the moment. We can optimise the
job though.
If we kept the old version and there were multiple catalogs per variant
then we would call the importer with the reset multiple times. The job
is iterating through each link only once though. So depending on the
ratio of catalogs to variants, I'm not sure which version would be more
efficient.
No version is properly dealing with the edge-case of multiple catalogs
per variant anyway. Imagine there are two catalogs with different stock
levels. Which one do we choose? Or do we add up?
And if the variant disappears from one catalog we still want to sell it
through the other. But depending on the order of processing, we may
reset the variant if it's missing in the last catalog. But let's worry
about that when it actually happens. Maybe it will be better to restrict
variants to one catalog.
There might be a delay before it gets sent, so it's better to record the time the event occurred at.
It would have been simpler to just add it to the data hash, but I felt it was an important detail for an event and should be at the top level along with event name.
In the case of order cycle opening, this is the same as opened_at. I've included this in the payload for clarity too.
Note that in the real world, this avoids a crash, but still requires the user to click the button two more times before it will work, with no hints as to why. So not a great help.
We now update or create line item fees instead of deleting them and
recreating them. This is to cover the case when a product has been
removed from an Order Cycle but we want to keep the fee already applied
on existing order. This was an issue only if the existing order got
updated after the product was removed.
- 2 new methods for reading either current/desired on hand/on demand
depending on variant state. Goal is to get rid of send method in View
- referring in on_hand/on_demand is in fact irrelevant. In the piece of
code, only desired on_hand/on_demand can be called as we are only in
new variant (non persisted) mode
- View does not use send method anymore, replaced by current_or_desired
- refactor of the spec -> 2 examples in one to get more speed.
- added 2 not to be persisted attributes aimed at dealing with the UI
- added them to the permitted list
- updated view to switch mode about on_hand/on_demand
that is: from an already persisted variant or not
- Not persisted deals with on_*_desired not to be persisted fields
- Persisted mode deals with regular on_* fields
- the corresponding spec for both on_hand/on_demand
The code was using the code from the environment variables to load a
reocrd from the database to then return the initial code again.
The only use of `DefaultCountry.code` is currently in the geocoder JS
compilation. Now it doesn't need the database anymore.
