They were all following the same format.
Note we need to group the `see_all` translation keys together (the same
way it's done with the `most_active` keys) so we don't have an unused
translation warning.
We're also moving the "see all" link in processes outside the feed
content; the same way it's done in debates and proposals and removing
unnecessary classes in the processes feed: the column class is causing
the processes not to be aligned with the debates above them, and the
margin bottom is not needed because the margin of the footer is already
enough.
Note we're using the code instead of the ID to get the goal in the URL.
IMHO this is what most people would expect; visiting a URL with a "7"
takes you to SDG number 7, and not to the one with "7" as a database ID.
In order to avoid tests (either automated tests or manual tests) passing
by coincidence due to the goal ID and the goal code being the same, I'm
shuffling the codes before entering them in the databse.
I've tried using `resolve` in the routes so the code is automatically
taken into account, but it doesn't work since `resolve` cannot be used
inside a namespace, and here we're within the `sdg` namespace.
Note using `params[:relatable_type].classify` is recognized as a
security risk by some tools. However, it's a false positive, since we've
added constraints to the URL so that paramenter can only have the values
we trust.
We do a similar thing with the settings helper, caching settings on a
per-request basis.
Using an instance variable in a helper reduces the amount of times we
need to calculate the cache key during a single request.
Even if Rails caches SQL queries per request, the test suite is faster
with this change, and we get rid of many redundant queries in the logs.
This way we avoid fetching each translation every time it's requested.
This reduces the amount of queries in the development logs and also
makes the test suite faster.
We were writing the same text over and over for the same translations.
Since they all serve the same function, it's perfectly fine for them to
have the same text, and so we can have a shared translation.
and its relation with the SDG goal model.
Add comparable module be able to sort collections of targets
by code attribute.
Co-Authored-By: Javi Martín <35156+javierm@users.noreply.github.com>
Since data for this model (title and description) is not generated in
CONSUL but by the United Nations, we aren't storing it in the database
but in our YAML translation files.
The reasoning is as follows. Suppose that, a few months after CONSUL
gets SDG support, a new language is added to CONSUL.
With YAML files, getting the texts in the new language would mean
updating CONSUL to include the new language.
But if we store these texts in the database, it means we have to update
the databases of all existing CONSUL installations, either each
installation by themselves (duplicating efforts) or running a rake task
(which we would have to write each time).
So we believe using translations works better in this case.
We're still storing records in the database with the code, so they can
be easily referenced via `has_many` or `has_many :through` associations.
A <header> tag is the natural place to have headings.
Since we already had the logo there, IMHO it makes sense to merge both
the <h1> tag and the logo together. We were already doing so in the
devise layout.
From the sceen reader users' point of view, having a link with the text
"CONSUL logo" is a bit confusing, since it seems to imply the link will
get us to the CONSUL logo. Using the organization name as the text of
the link makes more sense.
One thing changes, though. Before this commit, the first thing on the
page a screen reader user would hear about would be the organization
name. Now the language selector and the top links are announced before
the organization name is read. That's fine, since the actual first thing
these users will hear is the content of the <title> tag, which contains
the organization name as well.
The server_name variable isn't used since we removed the Apache task in
commit 012d5297e, db_server and config_files aren't used since we
removed the capistrano templates in that same commit, and full_app_name
isn't used since commit 94a7e13dc.
In some tables, we had "actions", and some columns were also links
pointing to some places. Having both of them at the same time is
confusing, particularly since traditionally the links in the columns
pointed to the same place as some of the actions (although that's not
the case since commit 48db31cd).
We're still keeping links in tables which don't have an action column.
For instance, the proposals table has a "select" button which would be
harder to use if we had action buttons next to it.
We added the background role to the production and preproduction
environments in commit d0b0782c4, but forgot to add it to the staging
environment as well.
The original devise_security_extension gem has not been maintained for
years. Its last release was version 0.10.0, and wasn't compatible with
Rails 5, and so we were using its master branch.
Since the gem was unmaintained, it was forked as devise-security and the
aforementioned master branch was released as version 0.10.1. This
version wasn't published in Rubygems, though, so we're now using the
first version that was published in Rubygems and had a release
announment [1].
Dependabot will probably open a pull request to upgrade to the latest
version, but for now I'm trying to keep the devise-security gem as
similar as the version we were using to make sure they're compatible,
particularly considering we're monkey-patching some of the modules
provided by this gem.
[1] https://github.com/devise-security/devise-security/releases/tag/v0.11.1
While Rails provides a lot of functionality by default, there's one
missing piece which is present in frameworks like Django or Phoenix: the
so-called "view models", or "components".
It isn't easy to extract methods in a standard Rails view/partial, since
extracting them to a helper will make them available to all views, and
so two helper methods can't have the same name. It's also hard to
organize the code in modules, and due to that it's hard to figure out
where a certain helper method is supposed to be called from.
Furthermore, object-oriented techniques like inheritance can't be
applied, and so in CONSUL customizing views is harder that customizing
models.
Components fix all these issues, and work the way Ruby objects usually
do.
Components are also a pattern whose popularity has increased a lot in
the last few years, with JavaScript frameworks like React using them
heavily. While React's components aren't exactly the same as the
components we're going to use, the concept is really similar.
I've always liked the idea of components. However, there wasn't a stable
gem we could safely use. The most popular gem (cells) hasn't been
maintained for years, and we have to be very careful choosing which gems
CONSUL should depend on.
The view_component gem is maintained by GitHub, which is as a guarantee
of future maintenance as it can be (not counting the Rails core team),
and its usage started growing after RailsConf 2019. While that's
certainly not a huge amount of time, it's not that we're using an
experimental gem either.
There's currently a conflict between view_component and wicked_pdf.
We're adding a monkey-patch with the fix until it's merged in
wicked_pdf.
We aren't using ActiveStorage, but Rails was including its routes
anyway.
In Rails 6.1 there will be an option to disable these routes [1], but
for now we're changing the line requiring "rails/all" to the values
generated by a new Rails application with the --skip-active-storage
flag.
[1] https://github.com/rails/rails/commit/3cf65bcb8
We can remove the `new_framework_defaults_5_2` file by using Rails 5.2
default options and overwriting the ones we haven't enabled.
We're disabling `use_authenticated_message_encryption` because, even if
we don't use it, some CONSUL installations might be using it, and
enabling this options would make it harder to decrypt existing encrypted
messages.
And we're disabling `cache_versioning` until we verify our cache keeps
working and expires as expected on production environments, particularly
for stats.
