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.
Since we're now allowing <h2> and <h3> tags in the description, we
remove the broken <h3> tag from quiz-question class. Since its content
is also in the <title> element, and in order to be consistent with other
show actions in the public area, we change this tag to <h1>.
We add <h2> tag in the "Share" heading and we replace the broken <h4>
tag above adding new styles.
To be consistent with the previous commit we update the text that appears
in the administration tables for discussions and proposals. Now instead of
"Proposals" and "Discussions" will appear "Title" which makes more sense
and is more consistent.
In the images.yml file we have a duplicate key with the same translation,
so we can remove it.
In the admin.yml file we have a duplicate key with different translation.
This translation is only used in 2 places in the application:
- In the administration table for collaborative legislation proposal index.
- In the <% provide :title do %> of the same page.
Although it is true that now the second translation (Title) is applied in
both cases, I think it makes more sense to use the first one (Proposals)
in the page title because it seems to make more sense and be more useful
to use "Proposals" instead of “Title”.
In order not to modify the behavior in the translation shown in the
administration table, we add human_attribute_name to obtain the expected
result.
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.
This is consistent with the component for balloting stats. We're about
to change both components, and the changes are easier to follow if
they're similar.
We're also using consistent names in methods.
To get the heading where a user voted, we were relying on the
`balloted_heading_id` field.
Our guess is this was done so the total number of users is the same as
the sum of users who voted on a heading. That is, if 2000 people voted
just on the "All city" heading, 1000 voted just on the "North district"
heading, and 500 people voted on both, instead of showing "3500 people
voted in total, 2500 voted in all city, 1500 voted in north district",
we show something like "3500 people voted in total, 2250 voted in all
city, and 1250 voted in north district".
However, this approach has some disadvantages.
The first disadvantage is, the stats aren't correct. In the case above,
2500 voted on the "All city heading", so the statistics for this heading
don't show reality.
The second one is we weren't considering the last heading where users
voted inside the budget being displayed, but the last heading where
users voted, period. That means that, if all the people above voted on a
later budget, the stats for the budget above would become "3500 people
voted in total, 0 voted in all city, and 0 voted in north district".
That also means we were including headings from previous budgets in the
statistics for more recent budgets when people hadn't voted on the
recent ones.
So we're removing the `balloted_heading_id` since its data is lost once
people vote on a new budget. And, in order to show the right stats and
simplify the code, we're no longer trying to add votes just to one
heading when users vote on several headings.
Co-Authored-By: Julian Nicolas Herrero <microweb10@gmail.com>
The <th> elements should be inside <tr> elements.
Since we're changing this code, we're also adding <thead> and <tbody>
tags because that's what we usually do and it makes it easier to select
<tr> tags from either the table head or the table body using CSS or
JavaScript.
