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.
When running multiple specs that have to overwrite the rails secrets,
it can happen that the condition:
"@cached_rails_secrets != Rails.application.secrets"
is not met and unexpected secrets are returned.
We have found this case while experimenting with tests related to the
Tenant secrets. In one case, assigning cached rails secrets to nil resulted in
a failure to detect when the 'rails.application.secrets' had changed.
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>
This check isn't necessary since commit 7e3dd47d5, since now we check
that the budget is present before creating the components which call
this method.
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.
Not sure why it was added in commit 9fb5019f0, but it made the table
look funny on some screens, particularly after adding the extra field
we're about to add.
In the commit: 315c57929a this code was added, but at that time this field
was no longer in use, even though it existed in the database.
I don't know why this line was added, but there seems to be no point in
keeping it.
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.
The `marker` variable is like a global variable inside the
`initializeMap` function, so assigning it inside the `createMarker`
function was changing its value in other places.
So we're using different variable names like `newMarker` in order to
make the code easier to follow. Now we "only" change the `marker`
variable in functions that modify the marker.
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.
It's causing annoying behaviour for desktop users when scrolling
the page to the bottom and there is more content below the
map.
The behaviour of touchable devices does not seem to be
affected by this change and keeps behaving the same.
