We were using `overflow: scroll` as a workaround with a problem we had
with the equalizer. But now we never need an extra vertical scroll bar,
and we only need an extra horizontal scroll bar on small screens.
Since the dashboard was using the class `admin-content` as well, we need
to apply to the dashboard the same changes we've done in the admin
section. I've extracted them into a mixin.
In some situations where JavaScript makes content disappear, the height
of the element calculated by foundation's equalizer isn't recalculated,
leaving blank space at the bottom of the page. I've seen cases where a
blank vertical space of 2000 pixels is on the page.
Using flexbox solves the problem, since CSS takes care of everything.
These changes fix a bug that causes categories
of a legislation process to be wiped on update
of the process. It also adds a regression test
for this fix.
While the browser gem is great, we don't need it in this case for such a
simple usage.
There are a few really small differences between this code and the old
one: matching `/MSIE/` will return true for Opera 12 and false for
certain versions of IE11. Since we're only rendering a comment for IE8
and below, we don't care about IE11, and Opera 12 is six years old and
its users won't be affected by the comment.
Note we're still using the browser gem because ahoy_matey depends on it,
but now it's an indirect dependency.
In this case using `joins` doesn't prevent N+1 queries to get titles for
every record, and since we cannot order translations with just SQL due
to fallbacks, we don't need it.
Automatic SQL injection checks were showing a false positive in this
scope; there was no real vulnerability here because foreign keys, table
names and locales were under our control.
Using `sanitize` we make sure the `href` attribute does not execute any
dangerous code. The possibility of a banner pointing to a dangerous URL
was very reduced, though, since only administrators can edit this
attribute.
We make the code easier to read and at the same time we remove a SQL
injection false positive regarding the use of `WHERE id = #{id}`.
We still get a warning about SQL injection regarding the `tsv =` part.
It's a false positive, since the value of that parameter does not
depend on user input.
This was actually a false positive, since our new regular expression
does the exact same thing. However, false positives generate noise and
make it harder to deal with real issues, so I'm changing it anyway.
We could add a more advanced regular expression, like
`URI::MailTo::EMAIL_REGEXP`. However, this expression marks emails with
non-English characters as invalid, when in practice it's possible to
have an email address with non-English characters.
It was being incorrectly detected as used in a dangerous send. We can
get rid of the warning by taking advantage of the `has_orders` method
and getting rid of this code.
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.
These actions are never called with query parameters in our application,
so there's no need to use these parameters in a redirect.
Note in the test 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.
Creating more than 25 records isn't necessary to test pagination; we can
stub the number of records per page in a test.
On my machine we save about one second per test with these changes.
The link to show stats for these polls is nowhere to be seen in the
application, and these stats are included in the budget stats, so it
makes sense to restrict access to them.
When defining abilities, scopes cover more cases because they can be
used to check permissions for a record and to filter a collection. Ruby
blocks can only be used to check permissions for a record.
Note the `Budget::Phase.kind_or_later` name sounds funny, probably
because we use the word "phase" for both an an attribute in the budgets
table and an object associated with the budget, and so naming methods
for a budget phase is a bit tricky.
The scopes `created_by_admin` and `public_polls` were very similar. I'm
using `created_by_admin` because `Poll.public_polls` feels redundant,
and the reason for that name is we should not name the scope `public`
because `public` is a ruby access modifier.
We were checking for `expired?` and `results_enabled?` in views and
helpers, when we've already defined a rule for accessing stats and
results for a poll.
This way we also fix a bug when stats were enabled but the poll wasn't
finished. In this scenario, the link pointed to the stats page, but when
clicking it we'd get a "you don't have permission" message.
Now the link doesn't point to the stats page anymore.
There's no reason to allow administrators to check stats and results for
a poll when it isn't finished or when results and stats are not enabled.
Now admins have the same permissions as everyone else.
* Add custom message for inclusion validation to include the allowed values.
* Force user to choose document_type from select lik the one shown at verification form.
* Convert stored document_type to a human readable text
This is a hack: we're making the textarea have the same size as CKEditor
so when it's replaced the page won't jump.
A very similar hack was removed in commit e844b0b2. Back then I thought
this was a small issue we could live with, but the user experience turns
out to be a bit annoying, and it makes tests fail sometimes because
Capybara is trying to click something when the page jumps, and so it
misses the click.
This feature wasn't properly tested nor reviewed, and after reviewing
several pull requests with a similar status and considering this pull
request is related to the public area of the web, we've decided to
remove it before releasing version 1.1.
This commit reverts commit 4f50e67a.
