c574a4d93a
The dates are saved on UTC times on the database. So, for example, if living in West Australia, `Date.current.beginning_of_day` will be stored as UTC's yesterday at 15:15:00, while `Date.current.end_of_day` will be stored as UTC's today at 15:14:59. When we use the `DATE` database function, PostgreSQL will select the records with the same UTC date as the current UTC date. However, we need the records with the same application date (as defined in `config.time_zone`) as the current application date. The test passed (for us) because we were using `beginning_of_day + 3.hours` to make sure we were creating records when the date in Madrid was the same as the UTC date. Using a ruby interval for the time condition solves the problem.
24 lines
762 B
Ruby
24 lines
762 B
Ruby
class DirectMessage < ApplicationRecord
|
|
belongs_to :sender, class_name: "User", foreign_key: "sender_id"
|
|
belongs_to :receiver, class_name: "User", foreign_key: "receiver_id"
|
|
|
|
validates :title, presence: true
|
|
validates :body, presence: true
|
|
validates :sender, presence: true
|
|
validates :receiver, presence: true
|
|
validate :max_per_day
|
|
|
|
scope :today, lambda { where(created_at: Date.current.beginning_of_day..Date.current.end_of_day) }
|
|
|
|
def max_per_day
|
|
return if errors.any?
|
|
max = Setting[:direct_message_max_per_day]
|
|
return unless max
|
|
|
|
if sender.direct_messages_sent.today.count >= max.to_i
|
|
errors.add(:title, I18n.t("activerecord.errors.models.direct_message.attributes.max_per_day.invalid"))
|
|
end
|
|
end
|
|
|
|
end
|