This code was introduced in commit 722a431b, but it stopped being used
in commit 7657a0e0.
The spec was failing sometimes because the method didn't order the
records, but the spec checked the records returned in a certain order.
Furthermore, the method `page` generated a potential conflict with
kaminari's `page method.
Since we removed the `best_in_place` gem, this method doesn't exist
anymore. We're replacing it with what the method actually does.
Note the test doesn't check the poll is correctly updated. We could add
a `visit proposal_dashboard_polls_path(proposal)` before checking the
"Show results" field, but then we would enter a race condition between
this request and the AJAX request. A proper solution would be to provide
actual feedback to the user so they know the poll has been updated, and
then checking that feedback is present in the tests.
It was only used in one place, and could easily be replaced.
Note we usually use HTML classes like `map-location` instead of
`map_location`, but I've kept the underscore for compatibility with the
previous version.
We have to doble check all emails deliveries from the dashboard.
Using a setting to skip all dashboard email deliveries for now.
Note that a rake task to activated the `Setting["dashboard.emails"]` will need to be addded when we want to activate deliveries of these emails.
We have two models called `Answer`: The `Answer` model and the `Poll::Answer` model.
This conflict ocurrs when trying to create a user generated poll for a proposal. from the Dashboard. In that case we are getting an exception, only in the development environment, as the class `Answer` is loaded before the class `Poll::Answer` which is the one we want to use.
With this commit we are explicitly requiring the correct model, solving the class conflict.
Before we used the standard poll url (vota/:id) for a user generated poll.
However this url is considered too important for this kind of polls, so we are changing it to a namespaced url (proposals/:proposal_id/polls/:id)
When requesting files like `/hackattempt.js`, the pages controller was
responding with 404 status code.
However, since the request was considered a JavaScript request (because
of the `.js` extension), the response was also considered to be a
JavaScript one, and since the request wasn't an AJAX request, our
protection from forgery was preventing a potential security issue by
raising an InvalidCrossOriginRequest exception.
By setting HTML as content type, we correctly respond with a 404 status
code.
More info:
https://die-antwort.eu/techblog/2018-08-avoid-invalid-cross-origin-request-with-catch-all-route/
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.
