- presence: true is redundant since Rails 5.0 BUT applies
with new default config of
belongs_to_required_by_default to true.
Lots of files with belongs_to_required_by_default = false
(backward compatibility).
So: deleting this setting implies to adding optional: true
- added 'NOT NULL' constraints so model constraints match
with contraints on DB tables.
- corresponding migration files to match AR Models &
DB tables
- rake tasks to check corrupt data (ie: NULL/nil in id fields)
- updated the todo
- presence: true is redundant since Rails 5.0 BUT applies
with new default config of
belongs_to_required_by_default to true
Lots of files with belongs_to_required_by_default = false
(backward compatibility)
So: deleting this setting implies to adding optional: true
- added 'NOT NULL' constraints so model constraints match
with contraints on DB tables.
- updated the todo
These config values are relatively static but in some cases they can be called many times in the same request (like rendering a report or a large list of line_items in BOM). These values will now only get fetched from Redis/Postgres once at most per request/job.
It allowed introspection of a dynamic state machine. But the only two
usages of this method only referred to the first state which is always
the same. Our complicated checkout logic needs more clarity and
introducing some hardcoded state names here can only help.
We want to link variants/products to external DFC SuppliedProducts to
trigger supplier orders when local stock is exhausted. This is the first
step to enable the link.
The refresh token is usually valid for a year but it can be revoked at
any time. When we try to use it and it's expired, we should remove it
from the account record and notify the user. They can then refresh the
authorisation.
This makes testing much easier. But probably also good for users to
revoke any access via OIDC apps. It also enables users to then connect
to a different account, or just renew the current connection.
The provider name and uid are currently stored on the user model but
it's better to move them to their own table. They are only needed in
certain situations, only some users have an account and we are now
storing a lot more.
This avoids unnecessary second message when left blank:
> can't be blank
> is not a number
Ok this is a little confusing. Why is there a separate presence check above, and why is it only for measurable units, when we still require a number for _all_ units? Because, for 'items', we allow a blank value then auto-set it to 1.
I don't know if it's really necessary, but that's how it currently works...
