We don't need to set this value. In commit f2ef27d3 I made a mistake
thinking `Globalize.locale` and `I18n.locale` should always be in sync,
but they're actually automatically in sync when `Globalize.locale` is
`nil`.
So the best way to avoid any issues is not to assign `Globalize.locale`,
and use `Globalize.with_locale` where necessary instead.
In theory it's possible to add a `host` parameter to a URL, and we could
end up redirecting to that host if we just redirect using query
parameters.
Generating the path using `url_for` with `only_path` solves the issue.
Note in the tests I'm using the `get` method because the `patch` method
wouldn't send query parameters. This doesn't mean the action can be
accessed through GET requests, since controller tests don't check route
verbs. Using feature specs doesn't seem to work because `controller` and
`host` parameters are filtered automatically in feature specs.
Also note I'm not testing every hidden/moderation controller because
they basically use the same code.
Our manual implementation had a few issues. In particular, it didn't
track changes related to associations, which became more of an issue
when we made investments translatable.
Using audited gives us more functionality while at the same time
simplifies our code. However, it adds one more external dependency to
our project.
The reason for choosing audited over paper trail is audited seems to
make it easier to handle associations.
We were monkey-patching FoundationRailsHelper::Formbuilder, which made
form customization difficult. We can inherit from it, which is the
standard way of extending what an existing class does, and make our form
the default one.
We were raising a `CanCan::AcessDenied` and were getting a 500 Internal
Server Error.
I've chosen to do the same thing we do in the ApplicationController.
There are other options to handle this request, like redirecting to the
login page or returning a 401 Unauthorized HTTP status.
New version of globalize uses RequestStore gem to store I18n.locale and
Globalize.fallbacks in a per request basis to avoid collissions between
different requests. This gem update broke Globalize.fallback results
because it tries to fetch fallbacks from RequestStore, where there is no
locale fallbacks definition.
We were filtering by winners investments for finished budget without
having in consideration other filters.
We want the default filter to be `winners` for finished budgets.
The test "Budget Investments Show milestones" was failing in certain
cases where `Globalize.locale` had been changed in a previous test.
Since having different values in `Globalize.locale` and `I18n.locale`
has proven to be an issue on the test enviroment, this commit also
changes application code in order to avoid similar situations on
production.
See issue #2718.
