Without this change, we were getting errors when manually creating an
annotation using symbols in the ranges hash (that is, `ranges: [{ start:
"/p[1] }]` instead of `ranges: [{ "start" => "/p[1] }]`.
Using symbols isn't really supported and it might cause strange issues
with code like: `@draft_version.annotations.find_by(range_start: ...)`.
However, this might be an extreme case and using symbols might work
properly most of the time (if not all the time), and we've been using
them in our demo for years.
So I'm not writing a test for this case because I'm not sure we should
support it, but I'm still allowing symbols so we don't get exceptions in
cases where everything might be working fine. Rails already adds Symbol
by default to column permitted classes [1], so it's safe to enable it.
[1] https://github.com/rails/rails/pull/45584/commits/c2b96e3e8
We were ignoring the draft version param when loading an annotation,
which could result in a strange situation where we load an annotation
and a draft version different than the one it belongs to.
Thanks to this change, we can simplify the code a little bit. IMHO the
`comments` and `new_comment` routes should have been added on member
instead of on collection, which would further simplify the code. I'm
leaving the routes untouched just in case changing the URL has side
effects on existing installations.
Apply new structure in the section that shows the comments icon together
with the number of comments so that it is easier to unify them into one
component.
Please note that we updated the comment-number class to comments-count
in order to simplify the css in the new component in the next commit.
This was the only place in the application where the comments icon was
included without the span with the class "icon-comments".
We unified with the rest of the application and removed the
"comments-count" class which is no longer needed.
Remove unnecessary span class "debate-comments".
We take advantage of this commit to also unify the format of the date
that appears next to the comments with the rest of the application. The
format that we removed is being used on the same page in the
"Participation phases" tab (I guess that was the reason for putting it
the same) but I think it makes more sense to use the date format that is
used in this kind section in the rest of the application.
Apply new structure in the section that shows the comments icon together
with the number of comments so that it is easier to unify them into one
component.
In this case we make only the text clickable and not the icon as in the
rest of the application. We're keeping the color and text-decoration so
it looks the same way it has looked until now, but we might change it
in the future.
We forgot to change the line rendering the image in commits 3574bf867c
and 810bdae37a, and so the custom image was being ignored.
Note that, in the test, we're stubbing a constant instead of adding a
new image. The main reason is that, if we add a new image, forks would
have to change the image when they change the `VALID_IMAGES` constant;
otherwise the tests would fail.
Apparently the dashboard branch wasn't updated after we extracted a
common head for all layouts in commit 6e4f697ce, so when said branch was
merged we reintroduced the duplication. Furthermore, we forgot to add to
the dashboard layout the changes we were applying to the common head
partial.
The Annotator library included all the dependencies it had at the moment
it was released, and so it was using jQuery 1.11.2 instead of the
version we use in the rest of the application.
Since including jQuery 1.11.2 raises a few warnings, we're removing it
so Annotator uses the same version of jQuery that is used in the rest of
the application.
We expected we needed to change some code in order to make it compatible
with jQuery 3.x. So far, everything seems to work fine, but we might
face errors in the future due to this change.
This release introduces an incompatibility in order to fix a security
issue when using YAML for serialization. We use YAML to serialize the
`ranges` column in the `legislation_annotations` table, so we have to
allow the `ActiveSupport::HashWithIndifferentAccess` class in order to
properly read this column.
Ideally we'd use a JSONB column for the ranges (like we do in other
places), but that would require migrating existing data.
Bumps [rails](https://github.com/rails/rails) from 5.2.7.1 to 5.2.8.1.
- [Release notes](https://github.com/rails/rails/releases)
- [Commits](https://github.com/rails/rails/compare/v5.2.7.1...v5.2.8.1)
---
updated-dependencies:
- dependency-name: rails
...
We changed the structure of the production environment file in commit
eb36b7e2e, but forgot to do so for staging and preproduction.
We're also changing the comments in the production environment file so
they use double quotes, like we do everywhere else.
After these changes, the staging and production environments are mostly
identical, and we could simply require the production environment
configuration in the `staging.rb` file. We aren't doing so because we've
just done changes affecting the preproduction environment and, since
Consul installations might have customized these files, it might be hard
for them to deal with all these changes at once.
We were already doing so by duplicating the code; now we're doing it
explicitly.
This is going to help because we're going to do a few changes in the
environment files, and this way we don't have to do everything twice.
Note that, after we're finished with these changes, the staging and
production environments will be mostly identical and we could simply
require the production environment configuration in the `staging.rb`
file. We aren't doing so because some Consul installations might have
customized these files and it'd be hard for them to deal with all these
changes at once. So, for now, they'll only have to deal with the
possible differences between their staging and preproduction
environments.
Changes to the preproduction environment that won't be applied to the
staging environment can be added like this:
require Rails.root.join("config", "environments", "staging")
Rails.application.configure do
config.log_level = :warn
end
We've been doing manually for too long ;).
The reason why we're assigning the author is it makes it easy to filter
pull requests by assignee on our kanban; it isn't so easy (actually,
might be impossible) to filter by author.
Without this condition, the kanban assignment would be run on every
CONSUL fork and that would result in unpredictable results since they
would try to write on our kanban, and they don't have permission to do
so.
Note that, much to my dismay :D, the code only works if we use single
quotes in the name of the repository owner; it doesn't work if we use
double quotes.
