When running delayed_job on reboot using Consul Democracy 2.2.0, we were
getting an error:
```
`require': cannot load such file -- sassc-embedded (LoadError)
from <internal:rubygems/core_ext/kernel_require.rb>:86:in `require'
from config/application.rb:1:in
```
No idea why this gem isn't detected when running `bin/delayed_job`.
When deploying with Capistrano, we use `bundle exec bin/delayed_job`,
and that works fine, so we're using it here as well.
We had already fixed this issue in the Cosul Democracy installer [1],
but forgot to configure the Cron job to do the same.
[1] https://github.com/consuldemocracy/installer/commit/3dc69eb6
The resolution of most devices is at least 640 pixels in at least one of
their dimensions. Since we need the width to be smaller than 640 pixels,
having a height of 479px wasn't realistic.
Doing so caused the tests checking the sticky "support proposal" tests
to fail because on 480px-high devices the sticky message covers the
whole screen.
This is a usability issue, but since I'm not sure how many people use
such a small window when browsing the web, for now I'm simply changing
the tests.
We're changing the width to 320px since it's the width required by the
Web Content Accessibility Guidelines 2.2. Quoting these guidelines [1]:
> Content can be presented without loss of information or functionality,
> and without requiring scrolling in two dimensions for:
> * Vertical scrolling content at a width equivalent to 320 CSS pixels;
> * Horizontal scrolling content at a height equivalent to 256 CSS
> pixels.
Note that, using a height of 256px, the sticky message would make the
application unusable, though. IMHO we'll have to get rid of the sticky
message sooner or later.
Since August 29, probably due to a change in the browser used by GitHub
Actions (since branches whose code we didn't change were suddenly
affected that day), many tests related to proposals are failing on
GitHub Actions. Although every time the test suite is run different
tests fail, on each run at least half a dozen tests fail.
Most tests have one thing in common: they click on an element on the
`proposals#show` page, and the click isn't done correctly.
One possible explanation is that the video included on the page causes
the page to scroll at the exact same time that Capybara is clicking on a
link, which results in a misclick.
I haven't been able to reproduce the issue on my machine, so I'm not
sure whether giving the video element a fixed height using CSS (so the
page doesn't scroll when the iframe is loaded) could solve the issue.
But, after using proposals without videos in the tests (except the tests
testing the videos themselves), all these tests are passing in the test
suite.
So, for now, we're simply removing the videos in the proposal factories.
Note this issue wasn't caused by the "no cookie" changes done in commit
ee64efe659, since running the tests in Cosul Democracy 2.1.1 (which
didn't contain those changes) also fails on GitHub Actions.
Until now, people had to edit the original route files in order to add
custom routes.
This was inconsistent with the other customizations, since we use custom
folders or files for customizing controllers, components, views, ...
(which you usually customize as well when adding a new route).
So now we're providing a file for custom routes, which will make it
easier to know which routes are not present in Consul Democracy by
default.
Note that, while it doesn't really affect the way the application
behaves (as long as the JavaScript code doesn't rely on the order it's
loaded) we're requiring `app/assets/javascripts/custom.js` after
requiring any files in the `app/assets/javascripts/custom/` folder. This
is done for consistency, since we load the content of
`app/assets/javascripts/application.js` after requiring everything else.
When we upgraded to Rails 7 in commit 8596f1539, we broke the custom
locales since now all nested folders in `config/locales/` are loaded by
default [1]. This meant that the custom folder was now loaded before any
languages whose code alphabetically goes after the word "custom".
As a workaround, we're overwriting the default locales paths so they
don't include the custom folder. We're doing this step before the
`add_locales` initializer; that is, before the default locales paths are
used.
Unfortunately, I haven't found a way to add a test for this behavior,
since we would need to add a file in `config/locales/custom` that
overwrites an internationalization key for an existing language, but
only during a specific test, and the i18n load path is evaluated when
the application starts up.
[1] See pull request 41872 in https://github.com/rails/rails/
So now we install a specific version of Node.js and use the packages
required for Debian Bookworm.
For consistency, we're also making them similar to the Ubuntu
instructions and installing rbenv instead of RVM. Since we now suggest
rbenv in both cases as well as in the macOS instructions, we're also
listing rbenv as the first option in the generic local installation
instructions.
This command simplifies some of the steps. However, there's a gotcha: it
might fail if the database requires username and password and they
haven't been configured before executing it.
On our regular README, this link used to point to the documentation
site, which made sense because the documentation used to be on a
different repository. Now that the documentation is on this repository
as well, we can directly link to that file.
And, on the documentation README, we can also link to the local
installation instructions, just like we do in other places.
