Remove state and mandatory columns from adjustments

[jhawthorn]

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. open and close are also states which need an explanation, vs finalized, which we've used elsewhere in the codebase with the same meaning. open also isn't ideal as it overrides Kernel#open, which causes state machine warnings unless configured to override that method.

This also removes the mandatory column, 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.

[jordan-brough]

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.

[jordan-brough]

is it worth having finalize/unfinalize (private, non-bang versions) for open/close?

[BenMorganIO]

I think it is.

[jhawthorn]

Added non-bang versions of finalize! and unfinalize!

[jordan-brough]

👍

[gmacdougall]

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.

[jhawthorn]

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.

[gmacdougall]

👍