- 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
- 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
This was actually shown in one place and represents a user-facing
change. But you weren't able to edit the field which means that only
very old enterprises would have had this field set and were not able to
change it anymore.
I searched au-prod and found the following values in the database:
- "Friday 31st January"
- "From 4pm, Monday 30 September"
- "From 5pm-7pm Monday"
- "Saturday 27 April 12noon"
- "January 31st/February 1st"
- "Saturday 1st February"
They seem specific to a certain order cycle and have no value as
fallback any more. Seems safe to remove.
We will add a migration to sanitise all existing descriptions but before
we do that destructive action, it's good to test this in a read-only
fashion first.
Most of the time this doesn't get called because source_required: false.
But sometimes it [does happen](https://app.bugsnag.com/yaycode/openfoodnetwork-uk/errors/66329690f4b6380007e8a4f8)
I have a feeling that source_required? could be moved to the superclass as payment_source_class.present?. But I don't know enough about this area of the system to try it...
- 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.
- 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.
