Since IRB has improved its support for multiline, the main argument
towars using a trailing dot no longer affects most people.
It still affects me, though, since I use Pry :), but I agree
leading dots are more readable, so I'm enabling the rule anyway.
In the `i18n_translation` initializer, we're overwriting the `t` helper
so calling it uses custom translations if they're available.
However, ViewComponent doesn't use the `t` helper but implements its own
`t` method. So, when calling the `t` method in a component, we weren't
using our implementation of the `t` helper, and so we weren't loading
custom translations.
Using the `t` helper in components solves the issue.
There was a test where we were directly testing a method in a component,
and that method uses the `t` helper. This caused an error when running
the test:
ViewComponent::Base::ViewContextCalledBeforeRenderError:
`#helpers` can't be used during initialization, as it depends on the
view context that only exists once a ViewComponent is passed to the
Rails render pipeline.
Using `render_inline` in the test and testing the generated HTML, as
recommended in the ViewComponent documentation, solves the issue.
Webdrivers doesn't seem to be working with GitHub Actions since Chrome
changed the way to download ChromeDriver [1].
Luckily, webdrivers functionality has recently been added directly to
selenium-webdriver, and version 4.11.0 is compatible with the new way to
download ChromeDriver.
So we're updating selenium-webdriver and removing webdrivers.
Note we now have to use the `Options` class instead of the
`Capabilities`. We're updating Capybara since its changelog mentions its
latest version also adapts these changes in Selenium.
[1] https://groups.google.com/g/chromedriver-users/c/qVPTFXnedw0
We were using two different sets of extensions but, since the markdown
code is always written by administrators, IMHO it makes sense to be
consistent and always render markdown code the same way.
* Add Tables option to Redcarpet in Legislation draft
* Allow table tags in Admin Legislation Sanitizer
* Add Test to render markdown tables in Legislation drafts
* Add Test for Admin Legislation Sanitizer
We include test for image, table and h1 to h6 tags and additional tests to strengthen the allowed and disallowed parameters
* Add Table from markdown test in System and Factories
* Add test to render tables for admin user
* Remove comment line about Redcarpet options
* Edit custom css for legislation draft table to make it responsive
And also `capybara-webmock' to the latest as the previous
one is not supported by selenium-webdriver.
The change in the rails_helper.rb file fixes a deprecation warning
related to desired capabilities after this upgrade.
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.
This methods performs much better when we need to load a lot of
globalized models translations and returns the best fallback translation
for the current language.
Previous to this commit the geozone link shown in the
legislation proposal page was pointing to the proposals
process feature instead to the legislation proposals.
Currently in the application we never show the original image, we always
show one of its variants.
This change removes the metadata of both the variants and the original
version so that if at some point we decide to show the original version,
we will no longer have to remember to remove the metadata.
Note that in the budgets wizard test we now create district with no
associated geozone, so the text "all city" will appear in the districts
table too, meaning we can't use `within "section", text: "All city" do`
anymore since it would result in an ambiguous match.
Co-Authored-By: Julian Herrero <microweb10@gmail.com>
Co-Authored-By: Javi Martín <javim@elretirao.net>
The `map` class is applied to the map element by LeafletJS; using it in
the container led to hacks like adding an `inline` class to fix the fact
that the container was using the `height` rule of the `.map` elements.
Even though we don't add styles for them, I'm adding the `budgets-map`
and `budget-investments-map` HTML classes so these elements can still be
easily selected with CSS and JavaScript.
Using a button for interactive elements is better, as explained in
commit 5311daadf.
Since buttons with "type=button" do nothing by default, we no longer
need to call `preventDefault()` when clicking it.
We were using `map_location` in one place and
`location-map-remove-marker` in another one. We usually use dashes in
HTML class names, we don't say "location map" anywhere else.
It was possible to remove a map location from a different proposal (even
one created by a different author) by modifying the hidden `id`
parameter in the form.
So we're making sure the map location we destroy is the one associated
to the proposal we're updating.
Since we're now using the `@proposal` instance variable in the
`destroy_map_location_association` method, we're calling that method
after loading the resource with cancancan.
We were rendering the whole sidebar again, which wasn't necessary since
most of it remains unchanged. This resulted in complicated code to pass
the necessary information to render the same map that was already
rendered. Furthermore, when users had been moving the map around or
zooming out, we were resetting the map to its default settings after
voting, which was potentially annoying.
This also fixes the wrong investments being displayed in the map after
voting; only the investments on the current page were displayed in this
case while the index displayed all of them.
Since this test was added in commit 78c6a30424 the
"current_password" was filled with an incorrect value.
This test did not fail because in previous versions of the
"devise-security" gem if this "current_password" was not valid
a "self.valid?" was performed which caused the error we are testing.
In version 0.17 (as can be seen in the following commit
https://github.com/devise-security/devise-security/pull/340/commits/41a99b67fe0)
if the "current_password" is not valid, related errors are still added
but the "self.valid?" code is removed, which is what causes the
expected error "must be different than the current password"
to appear in the "new password" field.
By adding a correct "current_password" in the test, we avoid this validation
for the "current_password" (which no longer includes the expected error)
and follow the natural flow of devise that does end up intercepting the error
for the new password entered.
These tests were failing with Ruby 3.0 because we were getting an error
when loading the `translations` association of the dummy class:
```
NameError:
uninitialized constant
DummyBanner::#<Class:0x000055630e4dccd8>::Translation
```
Specifying the `class_name` of the `translations` association solves the
issue.
It has been detected that for the :pt-BR, :zh-CN and :zh-TW locales,
the translate button was being displayed, but when requesting the
translation, the remote translation validation failed due to:
'''
validates :locale, inclusion: { in: ->(_) {
RemoteTranslations::Microsoft::AvailableLocales.available_locales }}
'''
That available_locales method did not contemplate these 3 languages
in the format used by the application.
To solve this problem the api response is mapped to return all
locales in the format expected by the application.
Add remote translation model test to ensure that a remote translation
is valid when its locale is pt-BR.
Co-Authored-By: Javi Martín <35156+javierm@users.noreply.github.com>
TranslatorText isn't compatible with Ruby 3, so we need to use a
different gem.
The 'translator-text' gem response was an array of one or more objects.
Now with the 'bing_translator' gem the response is an array with one or
several translated texts.
We remove the concept of object in the code. And we also remove the
"create_response" method from the specs since it is no longer necessary
to emulate that object and we can simply use arrays with texts to emulate
the new response.
Since we changed the way we integrate coveralls in commit 8ed8cc8b9,
we're getting 6 additional checks displayed in our pull requests.
We don't need these checks, and they only add noise. The only reason we
use coveralls is to know the test coverage in our master branch.
So we're changing the code so coveralls only runs on the master branch.
There's also a chance that the test suite will be faster because it
doesn't need to keep track of the coverage, although I haven't noticed any
significant differences during my tests.
I haven't found a more elegant way to say that a certain step should
only be run on push on master, so I'm setting the environment variable
we were already using.
The test that was not passing sometimes since commit 915999db4 because
we no longer created the budget before visiting the page that loads it.
So now we're forcing its creation with `let!`.
When accessing the valuation area, we were only displaying the
investments directly assigned to the current valuator, but we weren't
displaying the investments assigned to that valuator's group.
Using the `assigned_investments_ids` method, which takes the valuator
group into account, solves the issue.
We've also found an issue on our development machines: since we don't
have a unique index per `investment_id` and `valuator_id` in the
`budget_valuator_assignments` table, we've found duplicate records on
this table. When that happened, we were displaying the same investment
several times.
Since now we no longer join this table in the query returning the
investment, this issue is also solved, and we're adding a test for it.
We can now remove the call to the `distinct` method when calculating the
number of investments per heading.
