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 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.
"Participate in the final voting" was a concept which was hard to
understand since many people would think it was related to the
voting/polls section and that somehow there was going to be a "final"
poll.
So we use "Vote for budget projects" instead.
Thanks Pomerange for the suggestion.
We had the same texts four times, with slight variations in the case of
the management section.
We're unifying them under the "verification" i18n namespace, since the
texts are about actions which can be done depending on whether users are
verified or not.
Note the names of the i18n keys aren't very consistent, since we use
"debates" in plural but "proposal" in singular. We're leaving it like
this so existing translations aren't affected.
We were saying that actions marked with an asterisk were only possible
when users were verified. However, there were no actions marked with an
asterisk; instead, we didn't show these actions to non-verified users.
Besides, the concept of Census doesn't exist in many CONSUL
installations, where verification is done through other means, so the
text saying that only users on Census could do certain things wasn't
correct in these cases.
Due to that, we're removing the asterisk in the Spanish version as well.
We're also removing the asterisk in the default welcome pages, since
we're already saying which action can't be done until the account is
verified.
In the case of the residence verification page, we had asterisks but we
didn't explain what the asterisk stood for, so we're also removing it.
We used "retire" because we translated it literally from the Spanish
verb "retirar" which can mean both "retire" and "withdraw".
Note we're still using "retire" in database fields and method names;
changing that might make it harder to upgrade from a previous version of
CONSUL.
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
After commit 0214184b2, this method was only used in two places and was
only useful in one of them. IMHO it isn't worth it add a monkey-patch
for such a minor usage.
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>
Add a help text on admin budget show page and improve text from Admin::Budgets::HelpComponent in order to
clarify its functionality when we are using the wizard.
We were using very similar code for proposals, debates and investments,
so we might as well share the code between them.
Note we're using the `proposals.index.search_results` key even for
debates and investments. This will still work because the translations
shared the same text, but IMHO we should rename the key to something
like `shared.search_results_summary`. We aren't doing so because we'd
lose all the existing translations.
By default, in order to increase performance during IO operations, Ruby
doesn't immediately write to the standard output but uses a buffer
internally and writes the output in chunks [1].
It looks like this results in some output being missed when running
Docker Compose [2], so we're activating the sync mode, which flushes all
output immediately.
[1] https://ruby-doc.org/core-2.6.5/IO.html#method-i-sync-3D
[2] See issue 1118 in the sinatra/sinatra repository
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.
There are CONSUL installations where the validations CONSUL offers by
default don't make sense because they're using a different business
logic. Removing these validations in a custom model was hard, and that's
why in many cases modifying the original CONSUL models was an easier
solution.
Since modifying the original CONSUL models makes the code harder to
maintain, we're now providing a way to easily skip validations in a
custom model. For example, in order to skip the price presence
validation in the Budget::Heading model, we could write a model in
`app/models/custom/budget/heading.rb`:
```
require_dependency Rails.root.join("app", "models", "budget", "heading").to_s
class Budget::Heading
skip_validation :price, :presence
end
```
In order to skip validation on translatable attributes (defined with
`validates_translation`), we have to use the
`skip_translation_validation` method; for example, to skip the proposal
title presence validation:
```
require_dependency Rails.root.join("app", "models", "proposal").to_s
class Proposal
skip_translation_validation :title, :presence
end
```
Co-Authored-By: taitus <sebastia.roig@gmail.com>
We were getting a warning in Rails 6.0:
DEPRECATION WARNING: Class level methods will no longer inherit scoping
from `public_for_api` in Rails 6.1. To continue using the scoped
relation, pass it into the block directly. To instead access the full
set of models, as Rails 6.1 will, use
`ActsAsTaggableOn::Tag.default_scoped`.
In SQL, conditions like:
```
tag_id IN (x) AND taggable_type='Debate' OR taggable_type='Proposal'
```
Don't work as intended; we need to write:
```
tag_id IN (x) AND (taggable_type='Debate' OR taggable_type='Proposal')
```
Due to this bug, we were returning taggings for proposals without
intending to do so.
Since the code was very hard to read, we're also simplifying it.
When there was a custom JavaScript file, we weren't loading the original
one, meaning that, in order to customize it, it was necessary to copy
the whole original file and then changing it.
Now we're loading both the original and the custom file, so the custom
file can simply add more functions or overwrite the ones we'd like to
customize, without copying the whole file.
Existing copies of original files will still overwrite the whole file
and won't be affected.
Since we're going to remove Paperclip and Active Storage doesn't provide
any validations, we have to either write our own validation rules or use
a different gem.
We're using the file_validators gem instead of the
`active_storage_validations` gem because the latter doesn't support
proc/lambda objects in size and content type definitions. We need to use
them because in our case these values depend on settings stored in the
database.
