Remove state and mandatory columns from adjustments #279
Conversation
The mandatory column has had no effect since spree 2.2
|
awesome. nice deprecation strategy on open & close. since mandatory has been gone for a good while and since there's nothing we could map it to i kind of think as a developer i'd rather have it fail hard like you have it doing here so that any issues are quickly surfaced during testing. i suppose we could also deprecate it with no-op methods but what you have seems ok to me. |
|
|
||
| def open | ||
| ActiveSupport::Deprecation.warn "Adjustment#open is deprecated. Instead use Adjustment#unfinalize!", caller | ||
| unfinalize! |
There was a problem hiding this comment.
is it worth having finalize/unfinalize (private, non-bang versions) for open/close?
|
Added non-bang versions of |
|
👍 |
|
I'm a big fan of this. My only concern is how cross DB compatible the execute in the migration would be, only because I don't write SQL like that often. |
Should be entirely standard SQL. Works on mysql, postgres and sqlite at least. |
|
👍 |
Remove state and mandatory columns from adjustments
Move decorators to the correct folders and add EngineExtensions
This comes from a conversation with @jordan-brough a while ago.
The state machine on adjustment serves no purpose, as it allows changing between both states without restriction.
openandcloseare also states which need an explanation, vsfinalized, which we've used elsewhere in the codebase with the same meaning.openalso isn't ideal as it overridesKernel#open, which causes state machine warnings unless configured to override that method.This also removes the
mandatorycolumn, which has been unused since the Spree 2.2 adjustment changes. I'm not sure how this fits in with our versioning requirements, this column has been "gone" forever in that it hasn't done anything, but I could see an old store still setting it (or setting it to false) which would now error instead of just doing nothing.