Public view for suggested actions as well as resources has been
completelly redesigned.
Private side for this feature has been adapted as well in order to meet
the requirements.
The following parameters have been added to deploy-secrets.yml:
* **use_rvm**: yes/no
* **ruby_version**: Ruby version for rvm. Defaults to 2.3.2
* **repository**: Git repository. Defaults to the oficial repository
* **branch**: Branch to deploy. Defaults to master
* **rails_env**: Defaults to the stage.
Fixed migrations that required admin rights. Now first check if the postgress extensions are available. If so finish without doing nothin.
Added support for passenger.
Banners were not been shown in certain pages; now
they are.
Spec to check if the banner is been shown correctly
added. Before it was in admins specs, now it has it's
own spec out of admins folder.
* Delete all things related to banner images and styles (in code)
* Add a new test to check that the banner is showing correctly
* Update the specs accordingly to match the changes
Update dev_seed to set a random background_color and a font_color for banners (and remove everything about image and style)
Add a rake task to migrate the banner style to backgroun_color and font_color (so that the banners have the same colors than before)
Banner sections can be saved (one banner can appear in several sections)
If the hex color is changed in the textfield, the color of the color picker changes.
The db:dev_seed rake logs info as it progresses as information for the
developer. But that's not needed when ran from its tests file, and it
bloats the travis/rspec output with unnecessary information.
Now the task will always log info unless the rake task receives an
optional argument.
Date.new(...) does not take into account the current timezone, while other
parts of the application do. By default always parsing any date with the
default timezone and converting the resulting Time to Date would prevent
this kind of issues
DateTime.parse(...).in_time_zone gives an unexpected result, as the
DateTime.parse(...) will create a DateTime with +0000 time zone and the
`in_time_zone` will modify the DateTime to adjust to the default zone.
Maybe its better explained with an example, using 'Lima' as timezone:
DateTime.parse("2015-01-01")
> Thu, 01 Jan 2015 00:00:00 +0000
DateTime.parse("2015-01-01").in_time_zone
> Wed, 31 Dec 2014 19:00:00 -05 -05:00
And that's not the desired date but the previous day!
Why:
Both Newsletters and Email Downloads need the same logic: To extract the
emails from all the users in the segment that have newsletter flag
active, removing all empty email values.
How:
1- UserSegments#user_segment_emails holds that repeated logic and is used
on both Newsletter & EmailDownload.
2- Rename Newsletter#list_of_recipients to list_of_recipient_emails as
it is more descriptive. There is no need to pass entire Users around,
only the emails are needed at Mailer#newsletter method.
3- Cleanup Newsletter#list_of_recipient_emails model spec scenario
Why:
UserSegments are not only used for Newsletters or Email downloads, but
also for internal Global Notifications. We don't want to have that scope
hardcoded inside UserSegments as users that have opted-out from the
newsletter should still be recipients of global notifications.
How:
Removing the scope from the UserSegments `all_users` method that acts as
base for all the other segments. Including that `newsletter` scope only
on the places that is relevant:
* When listing recipients for a newsletter
* When downloading a listing emails that can be newsletter recipients
Also updated relevant tests
Why:
Budget Investment's valuators should be able to see internal valuation
comments thread at both show and edit views.
How:
At Valuation::BudgetInvestmentsController:
* Include CommentableActions to gain access to the entire feature, with
required resource_model & resource_name methods.
* Add the only possible order (oldest to newest)
* Load comments on both show & edit actions, passing `valuations` flag
to the CommentTree in order to only list those.
At CommentTree:
* Use `valuations` flag as instance variable to decide wich
comment threat to load: valuations (if relation exists) or comments.
Here's a better alternative than the first one. Added a new abstraction level from which are performed both types of census calls, while the logic of those is managed in their own library.