When importing another catalog, it's probably referring to external
product groups. Storing the external link allows us to group several
variants and replicate the same structure within OFN.
It just makes Rswag specs look more different to other request specs and
I found that discouraging. It's good to know that the parameter is just
specified with `let` and that it works exactly in the same way as `let`
in other specs.
The downside is maybe that it's not obvious that those `let` statements
have to correspond with the parameters for the request but error
messages will tell you if you got it wrong. And there's also the
`parameter` declaration to make that clear.
A while ago I was told that an absent stock limitation means unlimited
stock. But that can't be distinguished from just not wanting to update
the stock level.
In the meantime, a new stock policy model was proposed. But for now we
have a workaround, setting `-1` as value for unlimited stock.
* https://github.com/datafoodconsortium/ontology/discussions/112
- 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
Oh, and a transaction block. Because the controller after hooks tried to update the DB which resulted in
PG::InFailedSqlTransaction: ERROR: current transaction is aborted, commands ignored until end of transaction block
Even for a small rescue statement, it's worth adding a spec. You never know what might not be working!
Tags' rules are still coming from the old admin styles hence had to add
the new (admin_v3) border variable to the old one.
Has a hard coded colour value of #2e3132 as it has no access
to the new colours.