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.
On production environments the application wasn't loading because
the `SDG::Manager` class was defined in two places. We don't know
the exact reasons for the conflict and why these changes fix it.
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.
* Add a header element as component markup wrapper
* Allow component to receive an optional block
* Add reusable styles for header links
Co-autored-by: Javi Martín <javim@elretirao.net>
So tests won't fail when an institution changes the default organization
name.
The tests are also easier to understand now, since it's more obvious
where the "CONSUL" text is coming from.
