IMHO the best solution would be to completely remove this checkbox on
forms that require registration. Other than the fact that people have
already agreed with these terms when registering (although I guess these
terms might have changed since then) and that approximately 0% of the
population will read the conditions every time they agree with them,
there's the fact that these links are inside a label and people might
accidentally click on them while trying to click on the label in order
to check the checkbox.
I guess the idea is that these conditions might have changed since the
moment people registered. In a fair world, checking "I agree" would have
no legal meaning because it's unreasonable to expect that people will
read these conditions every time they fill in a form, so whatever we're
trying to do here would be pointless.
But, since I'm not sure about the legal implications of removing this
field in a world where you have to inform people that websites requiring
identification use cookies, for now the field will stay where it is.
In some places, we were using `blank` instead of `_blank`. Most browsers
treat `blank` like `_blank`, though, so most people didn't experience
any difference.
In another place, we were incorrectly passing the `target` option inside
an `options:` hash, resulting in invalid HTML.
This way it'll be easier to change them.
Note that there were two `.document-link` elements which aren't part of
a `.documents` element. We're renaming the HTML class of the link in
investments because it didn't contain links to download documents and
are slightly duplicating the CSS in the poll answer documents in order
to keep the `word-wrap` property.
We were adding <div> tags with the `images` or `documents` HTML class
prettly much every time we rendered a NestedComponent. We're now
including the HTML class inside the component, as we usually do.
We're also rendering the nested components directly, since it's been a
while since the partials were changed to simply render the components.
As far as possible I think the code is clearer if we use CRUD actions
rather than custom actions. This will make it easier to add the action
to remove votes in the next commit.
Note that we are adding this line as we need to validate it that a vote
can be created on a debate by the current user:
```authorize! :create, Vote.new(voter: current_user, votable: @debate)```
We have done it this way and not with the following code as you might
expect, as this way two votes are created instead of one.
```load_and_authorize_resource through: :debate, through_association: :votes_for```
This line tries to load the resource @debate and through the association
"votes_for" it tries to create a new vote associated to that debate.
Therefore a vote is created when trying to authorise the resource and
then another one in the create action, when calling @debate.vote_by (which
is called by @debate.register_vote).
In this commit, we have performed a refactoring to enhance code organization.
Several partials that were solely responsible for rendering components have been removed.
Instead, we are now directly rendering the components within the views where these
partials were previously used.
Note we're excluding a few files:
* Configuration files that weren't generated by us
* Migration files that weren't generated by us
* The Gemfile, since it includes an important comment that must be on
the same line as the gem declaration
* The Budget::Stats class, since the heading statistics are a mess and
having shorter lines would require a lot of refactoring
For the HashAlignment rule, we're using the default `key` style (keys
are aligned and values aren't) instead of the `table` style (both keys
and values are aligned) because, even if we used both in the
application, we used the `key` style a lot more. Furthermore, the
`table` style looks strange in places where there are both very long and
very short keys and sometimes we weren't even consistent with the
`table` style, aligning some keys without aligning other keys.
Ideally we could align hashes to "either key or table", so developers
can decide whether keeping the symmetry of the code is worth it in a
case-per-case basis, but Rubocop doesn't allow this option.
Since IRB has improved its support for multiline, the main argument
towars using a trailing dot no longer affects most people.
It still affects me, though, since I use Pry :), but I agree
leading dots are more readable, so I'm enabling the rule anyway.
In these commits 38ba5e159b and 8805037e2f we added the parameter
"vote_url" in the call to the partial "votes" in collaborative legislation
proposals.
It seems that this parameter is only used in the proposals module and not in
collaborative legislation proposals.
While it is true that in the partial "votes" in these commits this parameter
"vote_url" is referred to, in commit 276baedcf it seems to be removed.
For this reason, we remove the parameter.
Previous to this commit the geozone link shown in the
legislation proposal page was pointing to the proposals
process feature instead to the legislation proposals.
The only view that linked to this action was never used and so it was
deleted in commit 0bacd5baf.
Since now the proposals controller is the only one place rendering the
`shared/map` partial, we're moving it to the proposals views.
Since we're now allowing <h2> and <h3> tags in the description, we
remove the broken <h3> tag from quiz-question class. Since its content
is also in the <title> element, and in order to be consistent with other
show actions in the public area, we change this tag to <h1>.
We add <h2> tag in the "Share" heading and we replace the broken <h4>
tag above adding new styles.
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.
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.
This way we fix a bug we mentioned in commit 930bb753c which caused
links to documents to be broken when editing their title because the
title was used to generate the URL of the document.
Note we're still using Paperclip to render cached attachments because
this is the only case where we store files with just Paperclip and not
Active Storage.
With Active Storage, we render attachments just like any other resource,
using `polymorphic_path`. Paperclip included the `url` method in the
model; since the model doesn't have access to the request parameters
(like the host), this was inconvenient because it wasn't possible to
generate absolute URLs with Paperclip.
In order to simplify the code and make it similar to the way we used
Paperclip, we're adding a `variant` method accepting the name of a
variant and returning the variant.
This message is only shown in the `show` action, so it's shown at most
once in the whole page, so it doesn't take up too much space and it
isn't as overwhelming as if we were showing it on the index page, once
per debate.
We're only showing it when there are closed options, though, since
there's already a message to sign in to comment when the question
accepts open answers.
Just like we did in commit 0214184b2d for investments, we're removing
some possible optimizations (we don't have any benchmarks proving they
affect performance at all) in order to simplify the code.
The investement votes component `delegate` code was accidentally left
but isn't used since commit 0214184b2, so we're removing it now that
we're removing the `voted_for?` helper method.
The `legislation_proposals#index` action was never used because it used
the same URL as `legislation_processes#proposals`.
In commit 702bfec24 we removed the view, but we forgot to remove the
controller action, the route, and some partials which were rendered from
the index view.
Note that in proposal notifications we're writing the call to
render the component in the same line as the <div class="reply">
definition in order to be able to use the `:empty` selector when the
component renders nothing. No browser matches whitespace with the
`:empty` selector, so we can't add newline characters inside the tag. A
more elegant solution would be extracting the proposal notification
actions to a component and only rendering it if the moderation actions
component is rendered.
The imageable/documentable object is always the object the form builder
is based on; since we're already passing the form builder, we don't have
to pass the object as well.
The only exception are the poll answers. In this case, we're passing a
new answer as the object. That's OK; the same hack that we're using to
send the data to the answer URL without displaying existing attachments
causes the form to keep working the same way.
Using `<a>` tags with no `href` means these elements cannot be activated
by keyboard users, so we're replacing them with buttons.
In the future we probably want to add more consistency so all toggle
buttons use the same code. We might also add styles depending on the
`aria-expanded` property.
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.
