changed functions on verification.rb, the first thing they do is
return true whene skip_user_verification is active.
changed show_welcome_screen? on user.rb, now its shows the welcome
page even with te option active.
changed welcome.html.erb, now if the user see this view and the
option is activated, all 4 checks are green, not only 2.
There was a problem with the portuguese locale.
The locale was pt-BR, but `globalize_accessors` gem
doesn't allow the creation of methods using locales
with that format.
To avoid transforming pt-BR to pt and lose the distinction
of the different variations of the language, a function has
been added to transform pt-BR into pt_br (without changing
the locale itself). That way, when globalize uses the locales,
all of them will have a valid format (downcased and underscored)
AND they will be always the same (comparing pt-BR with pt_br
doesn't work).
Until we correctly make MapLocation relation with mappables a polymorphic
one... we'll need to return the investment_id and proposal_id values.
Right now it was returning the MapLocation ID, and the JS was making a
call searching for an Investment with the MapLocation ID... sometimes
finding a record with same ID but totally NOT the one associated to the
MapLocation.
The csv generation doesn't seem like a Model concern, at least not taking
into account the amount of lines of the method (36+). Just a simple ruby
class that encapsulates the logic makes it easier to read and maintain as
we increase the columns exported.. also customize in case other forks need
different values.
There's no good reason to call assigned_valuators(investment) when the
logic can be at the model.
Also removed the valuator_groups texts to be added in an independent
method
Why:
ValuatorGroup name should be unique and present to be able to identify
correctly each of them.
How:
- Adding a presence & uniqueness validation at the model
- Adding a sequenced value for name attribute at its factory
- Adding missing model spec that covers validations
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!
The user was able to vote as many investments as wanted in the first
heading voted. However in the second heading voted, only one investment
could be voted
This was due to the previous implementation, where you could only vote
in one heading. Note the `first` call in method
`heading_voted_by_user?(user)`
This commits simplifies the logic and allows voting for any investment
in any heading that the user has previously voted in
This method was used only in Madrid’s fork, but it is now needed to
complete the backport for voting in multiple headings
There wasn’t a test in Madrid, so here goes one too. Even though, the
responsibility should probably be moved soon to the `Budget::Heading`.
For consistency with the related methods and tests it has been left in
the investment_spec
Now that we have the option of voting in multiple headings per group,
the method of voting in a “different heading assigned” has become
deprecated and thus removed
Changing a group’s `to_param` to return the slug instead of the id,
breaks many tests in the user facing interface
We should use slugs in upstream soon, but it should be done in a
separate PR, bringing the whole slug implementation from Madrid’s fork
and the corresponding test coverage
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:
User with an empty email value (nil) should not appear in the recipient
list for a given UserSegment at Newsletters or Email Downloads.
How:
Using Enumerable#compact and Enumerable#select to filter out empty emails
Increasing Email Download feature spec and Newsletter model spec to cover
all possible scenarios including the nil email one.
Why:
A Newsletter can only be sent if the are available user recipient emails
and that means the `segment_recipient` value actually corresponds to a
function on the UserSegments class.
We could rely on the UserSegments::SEGMENTS constant as the list of
possible user segments functions that a Newsletter can use to gather
emails, so any value not included in that hash would not be valid.
But to be 100% sure the newsletter can get a recipients_list we should
just check if the UserSegments class has a method with same name as the
`segment_recipient` value.
How:
* Adding an validation method that checks if UserSegment has a method
with same name as the `segment_recipient` value.
* Adding an scenario to the Newsletter model spec to check this
Why:
Newsletter attribute `segment_recipient` is an integer to be used as
enum. There's no advantage to store a number instead of an string if the
ammount of elements in the table is not going to be huge, or we can take
advantage of using an enum.
Also maintaining both Newsletters enum paired with UserSegments::SEGMENTS
would be a maintenance burden.
How:
* Migration to change segment_recipient column from integer to string
* Removing enumeration from Newsletter model class
* Using UserSegments::SEGMENTS instead of Newsletter.segment_recipients
or integer values
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
