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)
We were sending a new request without checking the previous one had
finished, and if it hadn't finished, the test failed.
This test started to fail after upgrading to Rails 5, since we removed
the change done in commit eda47eff which set `config.allow_concurrency`
to `false` in the test environment.
While we could re-introduce that configuration option, which might have
side effects, an easier solution is to check an AJAX request has been
completed before sending a new request depending on the previous one
seems to be a more solid option.
Note this test failed with two possible errors: "undefined method
`heading' for nil:NilClass" and "stale element reference: element is not
attached to the page document". This change fixes the second error; it
might fix the first error as well, but since I couldn't reproduce it
locally, we'll only be sure when this test stops failing in travis
builds.
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.
