We had two different keys with the same text and were passing it as a
parameter. Since the text is the same in any case, we don't need a
parameter for it.
Note we are using the `proposals` i18n key instead of creating a new one
in a `shared` namespace one because creating a new key would mean that
we'd lose the already existing translations in Crowdin.
We were manually generating the IDs in order to pass them as data
attributes in the HTML in a component where we don't have access to the
form which has the inputs.
However, these data attributes only make sense when there's a form
present, so we can pass the form as a parameter and use it to get the
IDs.
We can now define a map as editable when there's an associated form,
which makes sense IMHO.
We were probably setting them separately to avoid having blank data
attributes in the HTML. However, when a data attribute is `nil`, Rails
doesn't write it in the HTML in the first place.
We're calling this method after setting the map location with
`map_location = MapLocation.new if map_location.nil?`, so the condition
`map_location.present?` is always going to be true.
The only view that linked to this action was never used and so it was
deleted in commit 0bacd5baf.
Since now the proposals controller is the only one place rendering the
`shared/map` partial, we're moving it to the proposals views.
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.
This is the only part of the sidebar that needs to be re-rendered after
an AJAX request adding or removing investments to a ballot, so having a
separate view just for it will make it easier to simplify the code.
This rule is broken in the Spanish files in which we have had to create the
headers with html in order to make the links work correctly.
These changes were made in commit: 3126fe769
This rule is broken when we have ".,;::!?" in the headers.
We have removed the ones with ":" but kept the ones
with "?", so this rule will always warn in these cases.
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.
Newer versions have more capabilities and also fix lot of errors,
usability and accessibility issues.
Note that we're using an external gem to rails-assets.org as it's
not supports the rails-assets pipeline. This gems wraps the
original one and make the code work with the default rails assets
pipeline as usual.
We were already using it because Rails adds the `Hash#except` method for
Ruby 2.7 and earlier, but since the method wasn't part of Ruby itself,
the Rubocop rule only works with Ruby 3.0 and later.
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.
