This way it's easier to customize colors, particularly when links use
the same colors as the text surrounding them.
Note that the `markdown-editor-header` isn't displayed since commit
76b7f66fb, which was probably an unintended side-effect. So we're
modifying the colors here as well instead of removing the element; we
might display it again in the future.
Also note the change in `.supported` only affects the proposals section;
budget investments use a different color for the `.supported` sucess
message. Not sure whether this was originally intended or done by
accident.
These elements were already using these colors because they inherited
them from their parent elements or Foundation already defined them.
Note that the only contents of `.comment-info` are: `.user-name` and
`.is-author`, `.is-association`, `.level-1`, ... and the link to the
comment. All of these elements were overwriting the `$text-medium`
color, so there's no need to set it. That means we can use the default
text color for `.user-name` without specifically setting it.
Doing so will help to immediately identify which administration you're
managing when using multitenant applications.
We might revert this change if we detect it causes usability issues in
the admin section.
Should hollow buttons use the same color as links do or the same color
as solid buttons do? In the default scenario, it doesn't matter, since
links and solid buttons use the same color. However, it matters when
people customize the application so links and solid buttons don't use
the same color.
I'm choosing to use the same color for solid and hollow buttons because
these elements are usually isolated and so from the UX perspective they
are similar; links, on the other hand, are often in the middle of some
text.
Note we're talking about links and buttons while many of the "buttons"
we use in the application are actually links styled as buttons. Here,
"buttons" means "things that look like buttons".
We were overwriting the color of the links, but not the color of the
links on hover.
Note we're removing the `!important` rule from the author link; after
testing it, it looks like it wasn't necessary.
We were using the wrong color since commit e2d540d20 because, by using
`@extend`, the compiled CSS had the styles for `.ui-state-hover` appear
before the styles for `.ui-state-default`.
They were added in Rubocop 1.24.0.
Even if we were already applying FileRead everywhere, this is something
we've manually fixed in the past. Another reason to add it is that these
rules are deeply related.
This rule was added in Rubocop 1.18.0, but we didn't add it back then.
Since we're applying it most of the time, we might as well be consistent
and apply it everywhere.
The scripts crashed when the `data` folder wasn't present, which is the
common situation in development environments or production environments
not using Capistrano, since this folder isn't under version control.
The `reload` method added to max_votes validation is needed because the
author gets here with some changes because of the around_action
`switch_locale`, which adds some changes to the current user record and
therefore, the lock method raises an exception when trying to lock it
requiring us to save or discard those record changes.
In case we receive consecutive requests we are locking the poll author record
until the first request transaction ends, so the author answers count during
subsequent requests validations is up to date.
This mixin was being called twice for the `.budget-investment-show`
selector; once in the CSS including this code for all the "Show
participation" pages, and once in the CSS for budget investments.
