So now:
* In the first few phases, no filters are shown (just like before)
* During the valuation phase, we show "Active" and "Unfeasible"
* During the final voting, we show "Active" (which now refers to the
selected investments), "Not selected for the final voting" and
"Unfeasible"
* When the budget is finished, we show "Winners", "Not selected for the
final voting" and "Unfeasible"
Now each investment is shown in one (and only one) of the filters
(except when the budget is finished; in this case we don't show selected
investments which didn't win), and we remove the confusing "Not
unfeasible" filter by only showing it during the valuation phase (before
filters are selected) and renaming it to "Active". We also rearrange the
filters so the default one for each phase is shown first.
The idea of using the "Active" text for investments which can be
selected during the selection phase and voted during the final voting is
experimental. Right now, for simplicity, since we assume filters will
always use the same text, we're removing the "Active" filter when the
budget is finished, since having both "Winners" and "Active" filters
would be confusing.
The last expectation we were using in this test is satisfied before
going back to the admin stats page, as the campaing2 name is not
present before clicking the `Go back` link. Because of this, the
test could end while the request thrown by the `Go back` link is
not completed yet, which can collide with the following test and
cause a flake spec.
As mentioned in commit 36d795f69, investment filters aren't that
important; actually, most citizens won't use them at all, and are there
mainly for transparency purposes.
So we're moving them to the bottom of the sidebar, just like the links
for selected/archived/retired proposals in the proposals section.
The `open` method can be used to open files or URLs and it's deprecated
in Ruby 2.7. In this case, it's clear we're dealing with a URL, so we
can use `URI.parse`.
The code was a bit strange, since it returned a value and had a side
effect: opening the URL. I'm not sure about the intention of the code;
my best guess is we wanted to test the URL exists and was accessible
before returning it (and, if that's the case, IMHO the code should be a
bit more explicit in order to show the intention behind it), but it
could also be an unintended side effect which was there by accident.
Now the URL is no longer opened; if the URL isn't accessible, we'll find
out when trying to connect to it with the Savon client.
In commit 5a4921a1a we replaced `URI.parse` with `URI.open` due to some
issues during our tests with S3.
However, there are some security issues with `URI.open` [1], since it
might allow some users to execute code on the server.
So we're using `URI.parse#open` instead.
[1] https://docs.rubocop.org/rubocop/cops_security.html#securityopen
It was accidentally introduced in commit 756a16f67. Pronto didn't warn
us because in that commit we deleted the code where the `group` method
was used.
It was accidentally introduced in commit 2b709f1a3. Pronto didn't warn
us because the blank lines were together after removing the blank lines
between them.
I'm not sure whether it now looks worse on extra large screens, but I'm
positive it looks much better on medium and large screens, particularly
when investments have images.
We're starting to use buttons instead of submit inputs where possible
because buttons are easier to style; for instance, buttons allow
pseudoelements. Rails has also changed the `button_to` helper to always
generate a <button> tag in recent versions [1].
In this case, buttons get on better with flex layouts, since by default
some browsers display submit inputs with `white-space: pre`, meaning
some of the text isn't visible on small screens.
[1] See pull request 40747 in https://github.com/rails/rails
Placeholders are hard to read due to their low contrast, and users might
want to read them after they're already gone, and so they cause both
accessibility and usability issues.
The installer creates the application in the following path:
home_dir: "/home/{{{ deploy_user }}"
We update the variable "deploy_to" in the deploy-secrets
file to be consistent with the installer.
While we are modifying the file we also update the "user"
variable in staging and preproduction sections with the
installer default value: "deploy_user: deploy" the same as
we already have in the production section.
In this PR (https://github.com/consul/consul/pull/4683) a new syntax was introduced
in the component specs to check that the component was not rendering.
It seems interesting to add this syntax to the rest of the cases and thus unify the way
we check that a component is not rendering.
The link to "See all investments" didn't have the `heading_id`
parameter, which resulted in the ballot information not being displayed
when in the voting phase.
We could modify the link to include the `heading_id` parameter, but IMHO
it's more robust to select the heading automatically when there's only
one heading. That way manually accessing the page without a `heading_id`
parameter will still work as if the heading had been selected.
There's no real point in linking to a page offering users to choose a
heading when there's only one heading to choose.
So we're linking to the investments index instead.
The interface was a bit confusing, since after clicking on "See
unfeasible investments" (or similar), we were on a page where no
investments were shown.
Besides, since commit 7e3dd47d5, the group page is only linked from the
"my ballot" page, through a link inviting the user to vote in that
group, and it's only possible to vote selected investments (which is the
default filter during the final voting phase).
The only reason we had these links here was these links weren't present
in the investments page. But they're present there since commit
04605d5d5, so we don't need them in the group page anymore.
Before the "valuating" phase, all investments have undecided feasibility
and none have been selected, so the filters would return no results
(except the "not_unfeasible" one, which would return everything).
We removed it in commit c322b2c4a because it was hard to know the
difference between "Feasible" and "Not unfeasible". We're renaming the
"Not unfeasible" filter instead.
We're also moving the "selected" filter so it appears before the
"unselected" filter, just like the "feasible" filter appears before the
"unfeasible" filter.
As mentioned in commit bc0f04075, a <select> field which submits its
form on change causes many accessibility and usability issues. In this
case there was also an incompatibility with the advanced search filter
which caused a bug solved in commit 541a5fa89.
So the question is where to position the filters and how to display
them. One factor to take into the account is how relevant these filters
are, particularly compared to the links to select the prefered order,
since we don't usually give users the choice of both filters and orders.
Our filters don't really make sense until the valuation phase starts,
since before that phase investments aren't selected nor their
feasibility is decided.
After that phase, the only phase where citizens are really involved
is the final voting; the rest of the phases are done by valuators and
administrators. In the final voting, citizens can only vote on selected
projects, and that's the default filter during that phase.
So these filters are mainly there for information purposes, and not to
help citizens in the phases where they're actually involved (accepting
projects, selecting projects and balloting).
Orders, on the other hand, play a crucial role during the final voting
phase. Since citizens might have already voted for a few projects and
have, let's say, 100,000€ left, ordering by price allows them to find
which projects are within their remaining budget.
In conclusion, orders are more important than filters, and so they
should have a more prominent place.
For consistency with the proposals section, where we've got some links
in the sidebar (bottom part of the page on small screens) providing a
similar funcionality, like accessing selected proposals or archived or
retired proposals, we're moving the investments filters to the sidebar
(bottom part of the page on small screens) as well.
A <div> can't be a direct child of a <ul>. In this case the <ul> tag
didn't make much sense because there isn't a list; just a map.
Note the `z-index` rule which was added in commit 25e1afea48 is ignored
because the map element is statically positioned. I'm not sure why it
was added; can't reproduce the rendering problem both that commit and
commit c5a749212 mention. Maybe back then the element had a `position:
relative` rule or similar somewhere.
