2abe9f27b5
These cases aren't covered by the `Rails/WhereRange` rubocop rule, but
IMHO using ranges makes them more consistent. Besides, they generate SQL
which is more consistent with what Rails usually generates. For example,
`Poll.where("starts_at <= :time and ends_at >= :time", time:
Time.current)` generates:
```
SELECT \"polls\".\"id\", (...) WHERE \"polls\".\"hidden_at\" IS NULL AND
(starts_at <= '2024-07-(...)' and ends_at >= '2024-07-(...)')
```
And `Poll.where(starts_at: ..Time.current, ends_at: Time.current..)`
generates:
```
SELECT \"polls\".\"id\", (...) WHERE \"polls\".\"hidden_at\" IS NULL AND
\"polls\".\"starts_at\" <= '2024-07-(...)' AND \"polls\".\"ends_at\" >=
'2024-07-(...)'"
```
Note that the `not_archived` scope in proposals slightly changes, since
we were using `>` and now we use the equivalent of `>=`. However, since
the `created_at` field is a time, this will only mean that a proposal
will be archived about one microsecond later.
For consistency, we're also changing the `archived` scope, so a proposal
is never archived and not archived at the same time (not even for a
microsecond).
19 lines
498 B
Ruby
19 lines
498 B
Ruby
module Flaggable
|
|
extend ActiveSupport::Concern
|
|
|
|
included do
|
|
has_many :flags, as: :flaggable, inverse_of: :flaggable
|
|
scope :flagged, -> { where(flags_count: 1..) }
|
|
scope :pending_flag_review, -> { flagged.where(ignored_flag_at: nil, hidden_at: nil) }
|
|
scope :with_ignored_flag, -> { flagged.where.not(ignored_flag_at: nil).where(hidden_at: nil) }
|
|
end
|
|
|
|
def ignored_flag?
|
|
ignored_flag_at.present?
|
|
end
|
|
|
|
def ignore_flag
|
|
update(ignored_flag_at: Time.current)
|
|
end
|
|
end
|