Now it's easier to change the investments filter. Previously we had to
go back to the budget index page, change the filter there, and then
select one heading.
Now the links to change the current filter in the budget index page
aren't needed anymore.
There was duplication between the index and the show views, and when we
changed the design of the phases in the index we forgot to change the
subheader in the other page as well.
There were some issues using `.budget.expanded`, like a link having that
class which would force us to a `:not(.button)` selector or similar,
making the CSS more complex.
Note this rule does still allow us to add new lines after opening tags;
it just makes sure that if we do, we also add it in closing tags.
Likewise, if we don't add it in the opening tag, it forces us not to add
it in the closing tag either.
I don't have a strong preference about either style; in these cases I've
chosen the latter because it seemed more common in our code.
Now the banner component accepts either a banner or a section and loads
the banner if it's a section, so we don't have to add the `@banners`
variable in several controllers.
We can use the current path as URL instead of passing it every time.
Passing the `page: 1` parameter is also redundant since by default the
index goes to the first page and the search form does not send any page
parameter.
We forgot to make this change when we started using "resolve" to
generate polymorphic nested resources.
The taggables_path method can be replaced with the polymorphic_path of a
class. It even works with nested resources, given the current page
already has the nested resources params (in this case, `budget_id` for
investments).
We didn't upgrade Turbolinks when we upgraded to Rails 5 so we didn't
upgrade too many things at the same time, and postponed it... until now
:).
Note upgrading Turbolinks fixes an issue with foundation's sticky when
using the browser's back and forward buttons. We're adding tests for
these scenarios.
Co-authored-by: Senén Rodero Rodríguez <senenrodero@gmail.com>
We were displaying two progress bars for the same thing, and hiding one
of them.
Displaying just one of them and readjusting the styles accordingly is a
bit more intuitive IMHO.
We're also getting the text inside the progress bar out of it; its
purpose inside an element with the `progressbar` role is to provide the
same information as the progress bar (which we aren't exactly doing,
although it could be argued that we do), and in order to be accessible
we should provide the same text in the `aria-valuetext` field, which we
aren't doing. This also simplifies our CSS, which was working because we
defined a padding which covered the height of the hidden extra progress
bar and would have needed quite a few changes if we kept just one
progress bar with text inside it. We can also remove a few CSS rules
which we added to override foundation's rules for the
`progress-meter-text` class.
We were setting it to 0, and so screen reader users might be confused by
it.
The easiest way to reuse the code and using it for both this attribute
and the width of the progress bar is to move this method to the voting
style, just like the other methods used in this view.
Note the progressbar ARIA role might not be right, since this isn't a
task which is "progressing", but an indicator of the amount spent and
amount available, which is exactly what the <meter> HTML5 tag was
designed for.
We might use a <meter> tag in the future. For now, I'm leaving it as it
is because I'm not certain about how well <meter> is supported in
accessibility tools, and because it's definitely not supported in
Internet Explorer 11, which we haven't officially dropped support for.
We were rendering an individual ballot, and then rendering all ballots
(including the already rendered one). So we can skip the first part, as
pointed out by microweb10 in the comments of pull request 3036.
We're passing the amount as a paramenter to the "remaining" text, so it
makes sense to pass it to the "amount spent" text as well.
Here we're also changing the I18n key to the text saying users can
change their vote, so it's easier to note the text is about changing
their vote, and not about the projects they have voted so far.
The `refresh_ballots` partial ignores the `investment` parameter
completely; instead, it iterates over the investments in the
`@investments` instance variable.
The main obstacle to extract this partial was probably the paths for the
flag and unflag actions.
Now that we use Rails 5.1 `resolve` method to handle nested resources,
we can use `polymorphic_path`.
Also note the code is a bit ugly because comments render a divider. We
should probably use a CSS border instead.
Co-Authored-By: taitus <sebastia.roig@gmail.com>
Since now it's possible to edit the budget investment during the
accepting phase, it does not really make sense to show the button to
just remove the image when the investment project can be fully edited,
and the image can be removed from the editing form.
We've added the option to remove an image from an investment. However,
removing the image did not expire the cache, so the rendered HTML still
included an `<image>` tag (which wouldn't show an image, since it had
been deleded) and a link to remove an image.
The new CSV report was more configurable and could work on proposals,
processes and comments. However, it had several issues.
In the public area, by default it generated a blank file.
In the admin section, the report was hard to configure and it generated
a file with less quality than the old system.
So until we improve this system, we're bringing back the old investment
CSV exporter.
This commit reverts most of commit 9d1ca3bf.
We're going to change CKEditor to an inline editor, and the "ckeditor"
gem doesn't provide an option to do so.
Since using `cktext_area` would automatically generate a "classic"
iframe CKEditor, we need to use `text_area` and load the editor using
JavaScript. Personally I prefer this option anyway.
Note in the jQuery selector we need to use `textarea.html-area`; using
just `.html-area` would fail if there's an error message associated to
the textarea, since Rails will add the `.html-area` class to the error
message.
Sanitizing descriptions before saving a record has a few drawbacks:
1. It makes the application rely on data being safe in the database. If
somehow dangerous data enters the database, the application will be
vulnerable to XSS attacks
2. It makes the code complicated
3. It isn't backwards compatible; if we decide to disallow a certain
HTML tag in the future, we'd need to sanitize existing data.
On the other hand, sanitizing the data in the view means we don't need
to triple-check dangerous HTML has already been stripped when we see the
method `auto_link_already_sanitized_html`, since now every time we use
it we sanitize the text in the same line we call this method.
We could also sanitize the data twice, both when saving to the database
and when displaying values in the view. However, doing so wouldn't make
the application safer, since we sanitize text introduced through
textarea fields but we don't sanitize text introduced through input
fields.
Finally, we could also overwrite the `description` method so it
sanitizes the text. But we're already introducing Globalize which
overwrites that method, and overwriting it again is a bit too confusing
in my humble opinion. It can also lead to hard-to-debug behaviour.
