Note we're excluding a few files:
* Configuration files that weren't generated by us
* Migration files that weren't generated by us
* The Gemfile, since it includes an important comment that must be on
the same line as the gem declaration
* The Budget::Stats class, since the heading statistics are a mess and
having shorter lines would require a lot of refactoring
Just like we did for budgets, we're doing the same thing in all the
places where we render background images attached by either regular
users or administrators.
This way we correctly render background images with characters like
brackets or quotes.
Just like we did in commit 0214184b2d for investments, we're removing
some possible optimizations (we don't have any benchmarks proving they
affect performance at all) in order to simplify the code.
The investement votes component `delegate` code was accidentally left
but isn't used since commit 0214184b2, so we're removing it now that
we're removing the `voted_for?` helper method.
We're not adding the rule because it would apply the current line length
rule of 110 characters per line. We still haven't decided whether we'll
keep that rule or make lines shorter so they're easier to read,
particularly when vertically splitting the editor window.
So, for now, I'm applying the rule to lines which are about 90
characters long.
This way it's easier to refactor it and/or change it.
Back in commit c156621a4 I wrote:
> Generally speaking, I'm not a big fan of helpers, but there are
> methods which IMHO qualify as helpers when (...) many Rails helpers,
> like `tag`, follow these principles.
It's time to modify these criteria a little bit. In some situations,
it's great to have a helper method so it can be easily used in view
(like `link_to`). However, from the maintenance point of view, helper
methods are usually messy because extracting methods requires making
sure there isn't another helper method with that name.
So we can use the best part of these worlds and provide a helper so it
can be easily called from the view, but internally make that helper
render a component and enjoy the advantages associated with using an
isolated Ruby class.
This way we generate the same HTML as we generate everywhere where we
manually generate lists of links. Having a blank space betwwen tags
results in a space being introduced when the elements are displayed
inline (or with `inline-block`).
So in places where we don't want that space between the elements we have
to use a flex layout.
This way screen reader users will be notified that the element is the
current one.
I'm not entirely sure whether `aria-current="page"` is more appropriate
than `aria-current="true"`, since it's a general helper which can be
used for any collection of links.
A list of links is a very common pattern in the web, and we use it in
many places. Here we're applying it to one of the most simple ones; the
help page.
Generally speaking, I'm not a big fan of helpers, but there are methods
which IMHO qualify as helpers when:
* They do not deal with application objects but mainly strings and
arrays
* They return text or an HTML tag
* Their logic is simple and splitting it into several methods is not
necessary
Many Rails helpers, like `tag`, follow these principles.
In commit 74083df1 we added the possibility to assign administrators and
valuators to budgets, so they would only manage the budgets they're
assigned to.
However, when filtering projects, we were still showing all
administrators and valuators as options to filter investments. It makes
more sense to only show the valuators and administrators assigned to the
current budget.
Note this change only affects the view, and so malicious users could
technically send any other administrator or valuator ID. In this case,
they would get empty results since those administrators/valuators
wouldn't have any investments assigned, so taking this case into account
is not necessary.
When an investment had been assigned a user tag and a valuation tag with
the same name, it appeared twice when filtering by tag.
This is because by design, in order to provide compatibility with scopes
using "select" or "distinct", the method `tagged_with` doesn't select
unique records.
Forcing the query to return unique records solves the issue.
We were very inconsistent regarding these rules.
Personally I prefer no empty lines around blocks, clases, etc... as
recommended by the Ruby style guide [1], and they're the default values
in rubocop, so those are the settings I'm applying.
The exception is the `private` access modifier, since we were leaving
empty lines around it most of the time. That's the default rubocop rule
as well. Personally I don't have a strong preference about this one.
[1] https://rubystyle.guide/#empty-lines-around-bodies
Settings are stored in the database, and so any changes to the settings
done during the tests are automatically rolled back between one test and
the next one.
There were also a few places where we weren't using an `after` block but
changing the setting at the end of the test.
- Display help text and example text according to
remote census configuration:
Examples with expecte results:
* With remote census without :date_of_birth and :postal_code:
-> "To verify a user, your application needs: Document number"
-> "Required fields for each user must be separated by commas and
each user must be separated by semicolons."
-> "Example: 12345678Z; 87654321Y"
* With remote census with :date_of_birth required:
-> "To verify a user, your application needs: Document number,
Day of birth (dd/mm/yyyy)"
-> "Required fields for each user must be separated by commas and
each user must be separated by semicolons."
-> "Example: 12345678Z, 01/01/1980; 87654321Y, 01/02/1990"
* With remote census with :date_of_birth and :postal_code required:
-> "To verify a user, your application needs: Document number,
Day of birth (dd/mm/yyyy) and Postal Code"
-> "Required fields for each user must be separated by commas and
each user must be separated by semicolons."
-> "Example: 12345678Z, 01/01/1980, 28001; 87654321Y, 01/02/1990, 28002"
When we reuse the partial '_setting_table' to render the 3 types
of remote census settings, we need customize setting_name key by
default to clarify the information to render.
- Add new param 'setting_name' to partial '_setting_table'
- Create new setting helper method to use new setting_name param
to display a more clarify setting name on table.
This spec was causing a side effect on another spec[2], making it fail 😌
I think it was because no translation had been called yet, in the failing spec, and so the the i18n backend translations had not been initialized, and was always returning empty translations for any locale. This might have been due to tampering with translations in the this newly introduced spec.
By forcing translations to load after this new spec, the other spec passes again
[2] https://github.com/AyuntamientoMadrid/consul/blob/master/spec/features/localization_spec.rb#L20
There where two issues with the current implementation:
- There was a possible duplication between looking up the language name in key "locale" and in key "i18n.language.name"
- The "default" option was not being picked up, as the fallback always returned the default locale's translation, "English"
With this implementation there is only a single place to put the language name: i18n.language.name. I think this place is easier to find and understand for Crowdin translators than a "locale" key hidden in general.yml
If the translation is not found we display the language key, instead of English, which makes more sense to me too 😌
Solution based on recent comments[1] on a related I18n issue
[1] https://github.com/svenfuchs/i18n/issues/365#issuecomment-419263847
