* 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
The new version of CKEditor loads the balloonpanel and balloontoolbar
plugins. Even if we don't need them, I haven't found a way to prevent
them from loading, meaning we have to precompile them.
This version solves a security issue:
https://ckeditor.com/cke4/release/CKEditor-4.11.0
Note this version adds a `ckeditor/samples` folder, which is
automatically added to the application's assets manifest even if we
remove all CKEditor references in our application. One of the files in
that folder makes ExecJS raise a syntax error, causing every page to
raise a 500 error.
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.
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.
Don't use <label> tags for things that are not labels, add a proper
<title> for the page, add a back link, remove an unnecessary
`inline-block` style for a header, localize dates and field names, ...
The interface could be further improve: proper diffs for long texts,
better separation between fields, ...
The name of the changed field is translated, values are truncated so
descriptions with thousands of character would make this table huge and
impossible to read, dates are localized, and values like arrays and
booleans are displayed properly.
Our manual implementation had a few issues. In particular, it didn't
track changes related to associations, which became more of an issue
when we made investments translatable.
Using audited gives us more functionality while at the same time
simplifies our code. However, it adds one more external dependency to
our project.
The reason for choosing audited over paper trail is audited seems to
make it easier to handle associations.
The current tracking section had a few issues:
* When browsing as an admin, this section becomes useless since no
investments are shown
* Browsing investments in the admin section, you're suddenly redirected
to the tracking section, making navigation confusing
* One test related to the officing dashboard failed due to these changes
and had been commented
* Several views and controller methods were copied from other sections,
leading to duplication and making the code harder to maintain
* Tracking routes were defined for proposals and legislation processes,
but in the tracking section only investments were shown
* Probably many more things, since these issues were detected after only
an hour reviewing and testing the code
So we're removing this untested section before releasing version 1.1. We
might add it back afterwards.
Tags and help links can be edited, but aren't used anywhere. Since we
don't know what the intended behavior was, I'm removing them for now.
My best guess is tags were supposed to be used so investments for a
budget can only be assigned tags present in the budget. Achieving that
behavior wouldn't be a trivial task.
We need to add a hidden field for each group of check boxes, so if we
don't check anything, the hidden field is sent to the server, indicating
nothing was selected. Without the hidden field, the server will not know
anything has been done to the check boxes.
The easiest way to do it is using `collection_check_boxes`, which also
adds labels to every check box.
They weren't caught by `i18n-tasks` because there are places were we use
`t("budgets.edit.#{variable}"`, which marks as used all translations
starting with `budgets.edit`
We were using two different systems to set translations in JavaScript:
to set the text for languages, we were using data attributes, and to set
the text for staff members, we were using AJAX calls.
I find data attributes keep the code more simple, since there's no need
to define an extra route and controller action. Furthermore, the user
experience is better because response times are faster.
So now both places use data attributes.
Unfortunately this feature wasn't properly reviewed and tested, and it
had many bugs, some of them critical and hard to fix, like validations
being skipped in concurrent requests.
So we're removing it before releasing version 1.1. We might add it back
in the future if we manage to solve the critical issues.
This commit reverts commit 836f9ba7.
The `and` and `or` keywords are not equivalent to `&&` and `||` and its
use is counterintuitive. Here's an example
```
good = true && false # good if false
bad = true and false # bad is true
```
The reason is `and` and `or` are control flow operators. So the code:
```
bad = true and false
```
Is equivalent to:
```
if bad = true
false
end
```
We were inconsistent on this one. I consider it particularly useful when
a method starts with a `return` statement.
In other cases, we probably shouldn't have a guard rule in the middle of
a method in any case, but that's a different refactoring.
We were very inconsistent regarding these rules.
Personally I prefer no empty lines around blocks, clases, etc... as
recommended by the Ruby style guide [1], and they're the default values
in rubocop, so those are the settings I'm applying.
The exception is the `private` access modifier, since we were leaving
empty lines around it most of the time. That's the default rubocop rule
as well. Personally I don't have a strong preference about this one.
[1] https://rubystyle.guide/#empty-lines-around-bodies
We were already using `find_by` most of the time.
Since there are false positives related to our `find_by_slug_or_id!` and
`find_by_manger_login` methods, which cannot be replaced with `find_by`,
I'm adding it indicating the "refactor" severity.
This will be the default behaviour in Rails 5.1, and it's a much better
approach.
I've checked the code and luckily there doesn't seem to be a single
place where we could accidentally stop the callback chain by returning
false in (for example) a `before_save` callback.
The jQuery html() function does not filter <script> tags, so if somehow
an attacker introduced a <script> in the translation, we would be
vulnerable to a XSS attack.
Note using $.parseHTML wouldn't solve the problem, since it doesn't
filter attributes in image tags.
Since changing the text of the part which doesn't have the count wasn't
very clean, I've added another <span> tag for the part with the
description, and so we can use jQuery's text() function to replace it.
We're going to upgrade our ruby version, and we need these tasks.
Note we now get a warning caused by `rvm1:install:ruby` invoking
`deploy:updating`. It doesn't seem to be an issue because we don't add
any hooks to `deploy:updating`, and neither do the rest of the gems we
use.
Old CONSUL nginx configurations will probably have a reference to a
unicorn socket. Making that file a symbolic link to a puma socket makes
it possible for the application to keep working without updating the
nginx configuration file.
Puma was adding commands to `rvm_map_bins`, which meant RMV1 wasn't
using the default value of `rvm1_map_bins`.
Changing the order we use to require `rmv1/capistrano3` and
`capistrano/puma` did not fix the issue.
Puma is the server we use in the development environment, so this way we
don't need to maintain two servers. Furthermore, puma seems to offer a
few advantages over unicorn (like multithreading) and no disadvantages.
Using the `_html` suffix in an i18n key is the same as using `html_safe`
on it, which means that translation could potentially be used for XSS
attacks.
Using the `_html` suffix automatically marks texts as HTML safe, so
doing so on sanitized texts is redundant.
Note flash texts are not sanitized the moment they are generated, but
are sanitized when displayed in the view.
