Note that the `create` action doesn't create an image but updates an
answer instead. We're removing the references to `:create` in the
abilities since it isn't used.
In the future we might change the form to add an image to an answer
because it's been broken for ages since it shows all the attached
images.
Adding, modifiying, and/or deleting questions for an already started
poll is far away from being democratic and can lead to unwanted side
effects like missing votes in the results or stats.
So, from now on, only modifiying questions will be possible only if
the poll has not started yet.
In this form, the only case where `poll` might be present without
`question.poll` being present to is going to be the `new` action. We can
assign the poll in the `new` action and get rid of the `poll` variable
in the form.
Until now, in order to edit an answer, we had to click on its title on
the table and then on the "Edit answer" link.
That was tedious and different from what we usually do in the admin
section. Furthermore, the code for the answers table was written twice
and when we modified it we forgot to update the one in the `show`
action, meaning the table here provided less information than the
information present in the answers tables.
Co-Authored-By: Javi Martín <javim@elretirao.net>
After removing a question from a poll it makes more sense to redirect to
your own poll show page in order to manage their questions.
Currently it is redirecting to the questions index page where all the
questions from all the polls are displayed and takes you completely out
of the context of the poll you are in.
In the future we will remove this index question page.
Actions :search_booths and :search_officers in admin polls controller
are moved to other controllers since commit 20e31133a for
:search_booths and commit 19ec7f93b for :search_officers.
This then allows us to remove the code that references these actions in
the controller and in the administrator abilities.
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.
Rubocop was complaining about Layout/EmptyLinesAroundAccessModifier in
the tags controller.
This issue was introduced in commit e76735031. Unfortunately, it looks
like Pronto doesn't detect this issue because the access modifier was
already there; only the lines below it were introduced in that pull
request.
This cop scans only the tests files by default, but we prefer to scan all
application Ruby files, so when a developer uses the class method
`I18n.locale=`, the cop will embrace using the method
`I18n.with_locale` instead. By doing this way, the cop will help
developers to avoid unexpected translation errors.
Quoting the Rails 6 guides:
> I18n.locale can leak into subsequent requests served by the same
thread/process if it is not consistently set in every controller. For
example executing I18n.locale = :es in one POST requests will have
effects for all later requests to controllers that don't set the locale,
but only in that particular thread/process. For that reason, instead of
I18n.locale = you can use I18n.with_locale which does not have this
leak issue.
Now we enabled the cop for all application Ruby files; we have to
remove the assignments at the controller level to set the request
locale. As Rails 6 guides suggest [1], we can use the `around_action`
controller callback to set each request locale without breaking the
rule.
This cop will warn CONSUL developers when using `I18n.locale`
assignment embracing them to use the `I18n.with_locale`instead.
[1] https://guides.rubyonrails.org/i18n.html#managing-the-locale-across-requests
We were missing a notice in this case. Not only this caused
inconsistencies in the user experience, but it also made it hard to add
an expectation in the test checking the request had finished before
making a new one. Simultaneous requests sometimes cause failures in our
test suite.
The idea to show the status of the existing features was done in commit
7339a98b74. Back then, we didn't have the separate `process.` prefix,
and so processes were enabled/disabled using settings like
`feature.debates` instead of `process.debates`.
IMHO making the information about the enabled features public could
potentially be a bit risky since it gives too much information about the
current status of the application.
Showing which processes are enabled, on the other hand, is pretty
harmless, and it's the reason why this feature was added in the first
place.
Currently with both seeds and dev_seeds, not only was this email not
displayed from the system emails section, but it also caused an error in
the application.
@email_to had an empty value and in the view we tried to access
@email_to.name which caused the error. We kept the same logic but
added the current_user to make sure it always has a valid value. We add
the current_user because the current_user is always present in this controller..
The current consul GraphQL API has two problems.
1) It uses some unnecessary complicated magic to automatically create
the GraphQL types and querys using an `api.yml` file. This approach
is over-engineered, complex and has no benefits. It's just harder to
understand the code for people which are not familiar with the
project (like me, lol).
2) It uses a deprecated DSL [1] that is soon going to be removed from
`graphql-ruby` completely. We are already seeing deprecation warning
because of this (see References).
There was one problem. I wanted to create the API so that it is fully
backwards compatible with the old one, BUT the old one uses field names
which are directly derived from the ruby code, which results in
snake_case field names - not the GraphQL way. When I'm using the
graphql-ruby Class-based syntax, it automatically creates the fields in
camelCase, which breaks backwards-compatibility.
So I've added deprecated snake_case field names to keep it
backwards-compatible.
[1] https://graphql-ruby.org/schema/class_based_api.html
Currently the application does not send any email to confirm the
account for already confirmed users. But we show a notice message
that may look like you will recive one:
"If your email address exists in our database, you will receive
an email with instructions for how to confirm your email address
in a few minutes."
In this commit we keep the original message, but send an email to
the user informing them that their account is now registered.
This way no one can know if someone else's account is confirmed and
we don't have to worry about GDPR either.
Co-Authored-By: taitus <sebastia.roig@gmail.com>
When customizing CONSUL, one of the most common actions is adding a new
field to a form.
This requires modifying the permitted/allowed parameters. However, in
most cases, the method returning these parameters returned an instance
of `ActionController::Parameters`, so adding more parameters to it
wasn't easy.
So customizing the code required copying the method returning those
parameters and adding the new ones. For example:
```
def something_params
params.require(:something).permit(
:one_consul_attribute,
:another_consul_attribute,
:my_custom_attribute
)
end
```
This meant that, if the `something_params` method changed in CONSUL, the
customization of this method had to be updated as well.
So we're extracting the logic returning the parameters to a method which
returns an array. Now this code can be customized without copying the
original method:
```
alias_method :consul_allowed_params, :allowed_params
def allowed_params
consul_allowed_params + [:my_custom_attribute]
end
```
The map feature was never implemented for debates (only for proposals
and budget investments) and it was crashing for debates because the page
didn't load the geozones. And we don't have a "geozone" field in the
debates form either.
So we're removing the map page alongside its (pending implementation)
tests.
