The Google response contains an `email_verified` field instead of a
`verified_email` field, and so we weren't treating verified Google
accounts as verified.
In the past, we've run into situations where we commited a version of
the schema.rb to version control which wasn't in sync with what you get
when you create the database and run the migrations. This is something
that might happen if you're working on different branches at the same
time, run the migrations in all those branches, and then commit the
current status of your database to your current branch. That will result
in a schema file which contains the database changes done in all these
branches instead of just the current one.
Although this hasn't happened to us for years, we see it happening
sometimes in other COSUL installations, and there's always a chance that
we make a mistake and do it again.
Until now, it wasn't a big deal because the installer sets up the
database by running `db:create db:migrate`, which runs the migrations
instead of using the `schema.rb` file.
However, we're going to add multitenancy using the Aparment gem, and
this gem uses the `schema.rb` file when creating a new schema for a new
tenant [1]. If the `schema.rb` file contains changes that shouldn't be
there, this will lead to different database schemas having different
tables and/or columns and future migrations might crash on production
when applied to some of these schemas. In other words, this mistake
could now result in a disastrous situation.
To help preventing that, we're adding a CI workflow that checks the
current `schema.rb` file is in sync with the database migrations.
[1] https://medium.com/infinite-monkeys/our-multi-tenancy-journey-with-postgres-schemas-and-apartment-6ecda151a21f#7e97
We were duplicating the asset host and the URL host in all environments,
but we can make it so the asset host uses the URL host unless we
specifically set it.
Note that, inside the `ApplicationMailer`, the `root_url` method already
uses `default_url_options` to generate the URL.
In the rare case of CONSUL installations who have changed the asset
host, this change has no effect since they'll get a conflict in the
environment files when upgrading and they'll choose to use their own
asset host.
Until now, when editing a specific environment, other CONSUL
installations had to edit the original file, which made it harder to
upgrade.
Now it's possible to change the default CONSUL settings using custom
files, making it easier to upgrade to versions of CONSUL which change
the original environment files (which is very common when upgrading
versions of Rails).
Before this change log generated by OmniAuth was sent to the STDOUT. Now
developers will find those gems log within the `app/log` directory as expected.
In the dev seeds, we were using `Setting["url"]/proposals`, but we can
use `proposals_url` instead, similar to what we do in the rest of the
application.
We can do a similar thing in the sitemap. This way the sitemap will also
work on installations who haven't manually set the "url" setting.
Since we aren't using `Setting["url"]` anywhere anymore, we're removing
it.
This setting was mainly redundant, since we already had the
`server_name` in the secrets. Furthermore, `server_name` is
automatically configured when running the installer, while
`Setting["url"]` had to be manually set in the admin section the
application was installed.
Note we're using `ActionMailer::Base` setting to generate URLs. Sounds a
bit strange, but it's a standard way Rails provides to generate URLs
outside the context of a request.
We've been using the `url` Setting for a long time, but since then we've
added a few references to `root_url` to this file, so we're now adding
consistency. We're also removing a now unnecessary condition.
We were using `Setting["url"]` to verify the content belonged to the
application URL, but we can use `root_url` instead.
Note that means we need to include the port when filling in forms in the
tests, since in tests URL helpers like `polymorphic_url` don't include
the port, but a port is automatically added when actually making the
request.
This task was added in commit 2b9b78e38. According to the notes in the
pull request introducing the change:
> If you have had [map validations] in production, you might want to run
> the rake task votes:reset_vote_counter to reset the cached votes
> counter. Otherwise, until there is another vote for a proposal, the
> counter will not be updated, and there might be some votes which are
> not yet displayed
In short, this was a task that was introduced for a specific release and
had to be run manually. So we can remove it now.
This task was "temporarily" removed in commit 7b6619528. Since that was
done three and a half years ago, right after the dashboard was
introduced, I think it's time to make this "temporary" measure a bit
more permanent ;).
By using the Rails `button_to` helper (which generates a form), and adapting the
response to `html` and `js` formats, the feature works with or without javascript
enabled.
We were rendering the `new` action, but that action doesn't exist.
Before commit ec861ca8e, we were rendering the `edit` action of an
answer, which was confusing as well.
Note that, when adding an invalid document, `@answer.documents` contains
that invalid document (which is not present in the database). Since
we're rendering the index, this new document would appear in the list of
the documents that can be deleted; to avoid that, we're kind of
"reloading" the answer object in the component by finding the record in
the database. We aren't using `@answer.reload` because doing so would
remove the validation errors.
We were using the same logic in four different places, so we're creating
a new class to handle that logic.
Note that I didn't find a way to delegate the `content` method to a
`Admin::TableActionsComponent`, so we're delegating the `action` method
instead. That means we need to create a method returning an
`Admin::TableActionsComponent`. We also need to cache this object;
otherwise we were getting an error when calling `actions.action` from
the `Admin::Poll::Questions::TableActionsComponent`.
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.
We need to update a couple of tests because a poll is created in the
tests with a timestamp that includes nanoseconds and in the form to edit
the time of the poll the nanoseconds are not sent, meaning it was
detected as a change.
Instead of having to add `beginning_of_minute` to deal with an issue
with Capybara filling datetime fields as mentioned in commit 5a0fde4048,
we can travel to the beginning of the minute so we don't have to take
the seconds into account.
The extra check to see the voter count has increased was redundant; we
already check the request has finished inside the
`vote_for_poll_via_web` method and we check all three voters are created
in the results table.
Updating the poll so it's in the past after starting the browser might
result in database inconsistencies while running the tests, so we're
using `travel_to` instead.
