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).
When retail variants are mapped to wholesale variants, we usually have a
some leftover stock at the end of an order cycle. For example, we
backordered a slab of 12 cans of tomatoes but our customers bought only
9 of those. Then we have 3 left for the next order cycle.
Even when the product is not available for backorder with the supplier,
we still want to sell off our leftover stock, the three cans of tomatoes
in our example.
And it might be that the product will come back in the future.
The previous version wasn't testing anything as there was no fees set
up.
Now we check that fees are applied as expected, and also that supplier
fees are applied only to the expected product.
This name better reflects what it's doing.
As this job is scheduled automatically by Sidekiq, I think there shouldn't be any jobs with the old name in redis. So I didn't bother keeping a placholder for the old name.
And Clean up unused include
After 10 minutes, I'd consider that it failed to open the order cycle. Who would want their products to sync, or get a notification at a random time during the order cycle?
Best viewed with whitespace ignored.
Being based on the DB value should be more robust.
This prevents an order cycle from being "opened" when it's already open. But note that the order cycle can become "unopened" (see OrderCycle#reset_opened_at).
Nice to see the database query count drop, but I must confess I don't know why!
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.
It was probably better to be explicit at each test, but this one is always repeated and approaches the line length, so I wanted to just define it once at the top.
