Commit Graph

9 Commits

Author SHA1 Message Date
Javi Martín
c574a4d93a Fix DirectMessage.today on different time zones
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.
2019-08-28 20:32:40 +02:00
Juanjo Bazán
b7d9ef6377 models inherits from ApplicationRecord 2019-04-17 17:40:56 +02:00
Julian Herrero
3ba961a2d7 Use double quotes in models 2019-03-14 17:25:43 +01:00
David Rodríguez
97331cb1c9 Fix direct_messages_max_per_day set to nil
When set to nil, it should mean not zero, but "infinite".
2017-10-23 12:15:31 +02:00
Bertocq
129e93dd12 Use Time.current converted to Date by the database DirectMessage today scope
Why:

* Database stores created_at as timestamp with the timezone, so when comparing DATE(created_at) to something we have to convert it to DATE as well with the postresql native function, but using Time.current instead of Date.current to take into account the user timezone
2017-06-14 01:15:26 +02:00
Bertocq
e14a5b2eaf Avoid using Date.today, better to use Date.current that takes timezone into account 2017-06-11 10:41:06 +02:00
rgarcia
8ee7d535ba generic message for max_per_day setting 2016-06-16 15:54:19 +02:00
rgarcia
25ebb325d1 limits maximum number of messages able to send per day 2016-06-16 11:10:26 +02:00
rgarcia
c3d06c8bd0 adds direct messages 2016-06-08 20:44:54 +02:00