This is one of Foundation's classes that only applies when its
parent element is a flex container, which isn't the case here since
commit dcec003.

There isn't a `ul` element here, so this rule doesn't apply.

We don't need it since it's only used for flexbox styles, and we
already have a `flex-grow` rule for the `h1` element which does the
same thing.

We're going to change these styles in order to fix a bug, and the
Foundation styles were getting in the way. Besides, we were overwriting
some rules and so now we're removing 6 properties while we're also
adding 6, so it isn't like the Foundation styles were helping us.

The menu didn't look properly on these screens since commit dcec003.

On small screens with enough horizontal space to show the menu button,
the logo, and the contents of the menu, all three elements were shown on
the same row, which looked broken.

Now the contents of the menu are shown below the menu button.

Note that, to force this, we're making the contents of the menu 100%
wide. That means links would take the 100% of the space, which would
make it easy to click on a link while trying to scroll when using
touchscreens. So we're making the links as wide as their text, which
also has a disadvantage: it's harder to click on narrow links like
"SDG".

We're changing the order of the elements in the HTML so the menu button
appears next to the menu it opens, with no logo between them, which IMHO
makes sense and makes it easier to understand the layout for people
using screen readers.

A small advantage of this approach is that on very narrow screens or
Consul applications having a very long word for "Menu", the menu button
appeared on top, the logo appeared below it, and the contents of the
menu appeared below the logo. Now the logo appears on top, the menu
button appears below it, and the contents of the menu appear below the
menu button.

So now it uses the same interface and styles as the main layout. On
small screens, it's easier to play with the menu when the button is on
the left because the menu it opens is aligned to the left.

Note that now we can get rid of the title-bar class; we didn't use the
styles in the public area since commit dcec003, and we were overriding
all the Foundation styles in the admin area with the exception of the
padding, which we no longer need.

We were using the same code for the button in both the public and admin
headers, so we're removing the duplication.

Since the menu and the button must go together, and the contents of the
menu are different for different layouts, we're passing these contents
using a block.

Note the ID of the menu was `responsive-menu` in the public section but
`responsive_menu` in the admin section. Since we usually use underscores
for IDs and dashes for classes, we're keeping the one with the
underscore.

We weren't using the `admin-top-bar` class since commit e6c1cf7, and
we can always use the `.admin .top-bar` selector if we need to. And the
`row expanded` classes basically give an element a width of 100%, which
is already the default width for block elements.

We were using partials to render components in order to ease the
transition of custom code from earlier versions of Consul. However,
that was back in Consul 1.4, and now these views looked a bit messy
since they sometimes rendered components and sometimes they
rendered partials.

So we're consistent with the rest of the code in the header, which
renders components and not partials.

That way it's possible to override the style without changing the HTML,
which is the hardest code to customize and maintain.

The `overflow: hidden` applied to the `.callout` selector made the full
width background invisible, meaning this section hasn't looked properly
on very large screens since  commit 701378d.

Instead of adding all the styles of a callout and then overwriting half
of them, we can simply add the half we need.

We can use the `link` mixin. Note this mixin uses anchor-color instead
of brand-color; by default, they're both the same, so we probably meant
anchor-color here.

Not sure why these properties were added, but they no longer seem to be
necessary.

The top bar padding was different on small screens when we were in the
admin section, so we're now applying the same padding everywhere.

Note we're still applying extra padding on medium/large screens because
in the public section we display our logo image, which has some blank
space. In the admin section we're emulating this blank space with
padding; we might change it in the future if we change our logo.

Also note we're using `0.8rem` instead of `$line-height / 2`. The reason
is tricky: there's a spec testing the reorder feature with drag and drop
in the poll questions answers administration, and that test fails when
the drop space is right at the bottom of the screen, which is what
happens when we use the `$line-height / 2` padding. A proper solution
would be to remove the inaccessible drag and drop feature and use a
different method to reorder the answers.

This way it'll be easier to change the code.

Now that all the code related to this model is in the same place,
changing it will be easier.

This way we can simplify the code dealing with the translatable
association.

I was finding this part hard to follow, but after changing the name of
the condition suddenly I understood what was going on.

The page was crashing when at least part of the content of the page had
been translated between the request showing the remote translations
button and the moment people pressed the button.

Fix menu on "wide" small screens

…ns_crash

Fix crash translating an already translated text

This way we reduce the number of system tests or, in some cases,
requests during system tests, making the tests faster.

We're still testing the interaction with the menu when users have the
right permissions.

In most sections, we had two specs testing what happens after accessing
one of the privileged areas. We're grouping the expectations and so
we've only got one test per area, making these tests faster.

Since the change on commit cbbe188 we added a Poll.current.any?
condition to show the officing link on admin menu to officers.

That condition doesn't have much sense since Poll results only can be
added after a poll has ended, and there may be only one active poll.

Always show poll officer menu to officers

We've experienced some caching issues with this code for years. We've
fixed some of them in commits 9979b53 and 3645c33, but we're still
running into other issues. In order to really cache this section, we'd
need to cache:

* Whether or not the investment should show the aside and vote/support
  buttons (we could do it by caching its budget)
* Whether its budget is balloting or finished (we could do it by caching
  its budget)
* Whether the current user is following the investment
* Whether the `remove_investments_supports` feature is enabled
* Whether the `community` feature is enabled
* The value of the `org_name` setting
* The value of the `twitter_handle` setting

We weren't caching all these elements, meaning that (for instance), we
didn't display the button to vote when a budget moved into the voting
phase if we had already cached this section without the button.

And chances are the list is incomplete. So, instead of trying to take
into account every single possible factor that should make us expire the
cache, we're restricting the cache so it only affects the content of the
investment. This is similar to what we do in the investments index,
where we cache the content of the investment but we don't cache the
vote/support buttons.

We're going to add more cases and the test for the link to the evaluate
would become too big, so we're splitting it.

This way it's still possible to access the "evaluation finished" filter
in the valuation investments index.

Using this method makes it more obvious that we're loading the same
investments in the budgets index as in the investments index.

We weren't allowing the `budget_id` parameter and then we were adding it
manually. We were also allowing other parameters that aren't used in the
valuation section.

So we're allowing budget and heading, which are the only parameter we're
offering filters for in the user interface. Note the `budget_id`
parameter doesn't seem to make sense because we're already inside a
`@budget.investments` statement, but the `budget_id` parameter is
required by the `scoped_filter` method.

The budget is loaded using a method which raises an exception if it
isn't found, so `@budget.present?` will always return true.

Don't cache related actions in investments view

We don't need groups to create headings since commit 20b1085, and
`let!` was used as a substitute for instance variables in commit
91c21b0, but it isn't necessary in this case.

We're also moving the tests, but we're keeping one system test in order
to test the controller and the navigation to get to this page.

Note we're slightly changing the order of the methods in the component;
the order of the instance variables was `user_`, `vote_`, `vote_`,
`user_`, which was hard to follow.

We had one method called `vote_count_by_heading` and another one called
`user_count_by_district`, when here districts refer to headings.

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.

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 <[email protected]>

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.

This way we reduce duplication.

Show admin heading stats for the current budget

Show link to evaluate investments with valuation finished

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.

…nvestments

Show valuator group investments to group valuators

The test that was not passing sometimes since commit 915999d because
we no longer created the budget before visiting the page that loads it.
So now we're forcing its creation with `let!`.

Fix flaky spec in budget supports admin stats

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.

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.

…s-keys

Remove duplicate keys

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.

Add description to Legislation questions

Do not show money with hidden money

It's already present in the consul/docs repository.

We're keeping the examples folder for now because it isn't in the
consul/docs repository yet.

We added them in commit 2e4601b, but it looks that they've never been
used.

This documentation is obsolete and there's documentation in the official
consulproject website containing user guides like this one.

We were getting many errors when trying to run them, from uninitialized
constant `HTTP` to undefined method `headers`.

We might move these examples to the documentation repository in the
future, but we need to look for possible side-effects first.

GitHub Workflows security hardening

Clean up doc folder

Since we changed the way we integrate coveralls in commit 8ed8cc8,
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.

Run test coverage just on the master branch

We were including it in the Object class, making its methods
available everywhere.

We usually use this approach because methods are easier to override and
stub.

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.

Bumps [rack](https://github.com/rack/rack) from 2.2.6.2 to 2.2.6.3.
- [Release notes](https://github.com/rack/rack/releases)
- [Changelog](https://github.com/rack/rack/blob/main/CHANGELOG.md)
- [Commits](rack/rack@v2.2.6.2...v2.2.6.3)

---
updated-dependencies:
- dependency-name: rack
  dependency-type: indirect
...

Signed-off-by: dependabot[bot] <[email protected]>

…r/rack-2.2.6.3

Bump rack from 2.2.6.2 to 2.2.6.3

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 <[email protected]>

Use Bing Translator instead of TranslatorText

Bumps [rack](https://github.com/rack/rack) from 2.2.6.3 to 2.2.6.4.
- [Release notes](https://github.com/rack/rack/releases)
- [Changelog](https://github.com/rack/rack/blob/main/CHANGELOG.md)
- [Commits](rack/rack@v2.2.6.3...v2.2.6.4)

---
updated-dependencies:
- dependency-name: rack
  dependency-type: indirect
...

Signed-off-by: dependabot[bot] <[email protected]>

…r/rack-2.2.6.4

Bump rack from 2.2.6.3 to 2.2.6.4

I thought SelfClosingTag was enabled since it was on the list and the
`enabled: false` got lost among all the `enabled: true`. ERB Lint 0.1
and later will also add RequireInputAutocomplete as a default linter,
and we're not interested in it, at least for now.

So, just like we do for Rubocop, we're disabling all linters and
enabling the ones we use explicitly.

We also need to update pronto-erb_lint since the old version depended on
erb_lint 0.0.x.

It's a default linter in erb_lint 0.3.0, and it's useful during
development since I'm always unsure about the right way to add ERB
comments.

Bump erb_lint from 0.0.37 to 0.3.1

It doesn't make much sense that by default we use one server on
production on two servers on preproduction.

Note we're keeping `server1` instead of using just `server` in order to
keep compatibility with existing installation.

We were using `server` on staging but `server1` and `server2` on
preproduction and production.

The reason behind it is we've always used one server on staging but
sometimes we've used several servers on preproduction and production.

However, this is a bit of a mess on installations which have only one
server on preproduction or production and need to use the `server` key
for the staging environments but `server1` for other environments.

So, in order to keep compatibility with existing Consul installations,
we're now allowing either `server` or `server1` on any environment.

So now it's similar to our database example file.

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.

…production

Use only one server when deploying to preproduction

Disable scroll wheel for zooming in favor of map zoom buttons

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.

Note the structure of the Gemfile changes slightly because Ruby 3.0
includes a new version of the Bundler gem.

In Ruby 3.0, Regexp and Range literals are frozen objects, and so we
don't need to freeze them.

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.

Upgrade Ruby to version 3.0.6

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.

Bump Leaflet from 1.5.1 to 1.9.3

Since this test was added in commit 78c6a30 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
devise-security/devise-security@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.

Bumps [devise-security](https://github.com/devise-security/devise-security) from 0.16.0 to 0.17.0.
- [Release notes](https://github.com/devise-security/devise-security/releases)
- [Commits](devise-security/devise-security@v0.16.0...v0.17.0)

---
updated-dependencies:
- dependency-name: devise-security
  dependency-type: direct:production
  update-type: version-update:semver-minor
...

Signed-off-by: dependabot[bot] <[email protected]>

Bumps [nokogiri](https://github.com/sparklemotion/nokogiri) from 1.13.10 to 1.14.3.
- [Release notes](https://github.com/sparklemotion/nokogiri/releases)
- [Changelog](https://github.com/sparklemotion/nokogiri/blob/main/CHANGELOG.md)
- [Commits](sparklemotion/nokogiri@v1.13.10...v1.14.3)

---
updated-dependencies:
- dependency-name: nokogiri
  dependency-type: indirect
...

Signed-off-by: dependabot[bot] <[email protected]>

…r/nokogiri-1.14.3

Bump nokogiri from 1.13.10 to 1.14.3