We can use `polymorphic_url` instead of manually setting the domain
every time.
This is a bit of a hack in order to comply with the validation rule
which says related content must start with the URL defined in
`Setting["url"]`.
The `parameterize` method uses the `I18n.transliterate` method, whose
documentation says:
```
I18n.transliterate("Ærøskøbing")
=> "AEroskobing"
I18n.transliterate("日本語")
=> "???"
```
That means we can't use it for dictionaries where characters don't have
a transliteration to the latin alphabet.
So we're changing the code in order to only transliterate characters
with a transliteration to the latin alphabet.
Note the first example ("Česká republika") already worked with the
previous code; the test has been added to make sure accented characters
are handled properly.
We were testing the creation of newsletters and admin notifications for
each existing segment, which IMHO is a bit overkill, considering how
slow system tests are.
So far we don't have any reasons to believe creating newsletters and
admin notifications will only work for some user segments, so we're
testing a random one instead.
Running these tests on my machine is now about 15 seconds faster.
This way we don't have to use the `send` method in other places, like
the AdminNotification class, and we can change the internal
implementation at any point.
We're going to add geozones as user segments, so it's handy to have the
method in the UserSegments class.
We're also changing the `user_segment_emails` parameter name for
consistency and simplicity.
We're going to make it dynamic using the geozones. Besides, class
methods can be overwritten using custom models, while constants can't be
overwritten without getting a warning [1].
Makes the definition of segments with geozones a little cleaner. I
think it’s worth it, compared to the slight memory gain of using a
constant [2].
[1] warning: already initialized constant UserSegments::SEGMENTS
[2] https://stackoverflow.com/questions/15903835/class-method-vs-constant-in-ruby-rails#answer-15903970
Programmers can take advantage of this feature when defining custom
default settings. And, since many CONSUL installations had custom
changes in the `custom/verification/residence.rb` model and those
changes might use regular expressions, we're making it easier to migrate
that code to the new system to define valid postal codes.
We aren't documenting this feature in the description in the admin
section because most administrators don't know what regular expressions
are.
Note that, in order to simplify the setting, we already define the `/\A`
and `\Z/` characters. So, if the custom code had something like
`postal_code =~ /^280/`, the setting would have to be "280*" (without
the quotes) or, in order to comply with a length validation,
"280[0-9]{2}" (without the quotes).
We were using the word "registered" in English as an equivalent of the
Spanish word "empadronado". However, the term "registered" is very
confusing because it might be understood as being registered in the
CONSUL website.
In the message, we're saying "cannot participate" in order to make the
message consistent with the message regarding the required age.
Due to the way Madrid handled postal code validations (see issue 533),
by default we were requiring everyone to validate against the local
census *and* to specify valid postal codes.
This could be useful in some cases, but in other cases, the census
validation will be enough and there'll be no need to manually define the
valid postal codes. Besides, some CONSUL installations are used in
organizations or political parties where the postal code validation
doesn't make sense.
In some countries, postal codes are defined with a dash in the middle,
so we're using a colon to define ranges instead. We could also use two
dots, like in Ruby ranges, but IMHO this would cause typos since people
would enter codes separated with three dots or just one dot.
We weren't using the `be_valid` matcher because we had errors in the
census data.
Removing the `before_validation` callback and using a method to get the
census data instead allows us to stub the `census_data` method in the
tests, and so we can use the `be_valid` matcher instead of calling
`valid?` manually and then checking for errors.
The `commentable_url` method wasn't updated when we added legislation
proposals.
Back when we first created this method, we couldn't pass budget
investments or topics directly to `polymorphic_url` because they are
nested resources. That isn't the case since commit ff93f5a59, so now we
can simplify this method.
We're keeping the `commentable_url` method for now in order to keep
compatibility with custom changes that might use it, although this
method isn't consistent with the `commentable_path` method (which
receives a comment, and not a commentable), and so we might have to
revisit this code in the future.
This test was failing sometimes. One possible cause (although it might
not be the only one) is we were querying the database with
`Campaing.last` after starting the process running the browser with a
`visit`. In the past doing so has resulted in database inconsistencies
while running the tests.
Since after running the test more than 1500 times we weren't able to
reproduce the failure, it's possible that this change doesn't fix the
issue which caused the test to fail, but in the worst case scenario we
reduce the number of possible reasons why it fails.
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.
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.
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.
There was an edge case where we could access the headings index without
sending the mode parameter in the URL. That meant when sending the
headings form we could send a form with the mode hidden field set to an
empty string. When that happened, the returned text was
`t("admin.budgets.help.#{i18n_namespace}.`, which returned a hash.
Using `multiple` when an empty strin is received solves the issue.
The text "Groups and headings" might cause users to think both groups
and headings have the same hierarchy, and wonder whether what they
immediately see are groups or headings.
Using "Heading groups" we make it clear that what comes immediately is a
group, and then we see each group has headings.
Since the message might appear several times on the same page, it's
useful to give a bit more context. Besides, usability tests show that
when there's a group with no headings, there's no clear indication on
the page that the group is actually a group and not a heading.
We're also adding some emphasis to the group name in the "Showing
headings" message, to be consistent with the emphasis we've
added the the group name in the "No headings" message.
Captions benefit blind screen reader users who navigate through tables,
particularly in this case because we potentially have several tables
with headings (one table per group), so when navigating through tables
it might be hard to know which group the headings belong to.
In this case they also benefit sighted users. Usability tests have shown
the "Groups and headings" section is a bit confusing, so adding a
caption like "Headings in Districts" helps clarifying Districts is a
group and the table refers to headings in that group.
The very same table is rendered in the "headings" step of the budget
creation wizard. However, in that case the information of the caption is
redundant because the page is specific for headings belonging to a
certain group. We're making the element invisible but still keeping it
for screen reader users in order to ease their navigation through
tables.
The population field is optional and only used for statistic purposes,
and the content block feature is also secondary, so IMHO it's OK if we
don't display it in the index; if administrators need this information,
they can see it by going to the "edit heading" page.
With this change it's easier to navigate the table on small and medium
screens. Actually, the whole page is easier to navigate, since we
greatly reduce the cases where a horizontal scrollbar is present.
The buttons to create polls associated with a budget were too prominent,
appearing on the table as if they were as used as the link to manage
investments. Most CONSUL installations don't use physical booths, and
would probably wonder what that button is about.
We're moving it to a more discrete place, at the bottom of the budget
page. This way we can also split the action in two: on budgets not
having a poll, we display the button in a not-so-accessible position (at
the bottom of the page), since this button will only be used once per
budget at most. Once the poll has been created, it means this feature is
going to be used, so we display a link to manage ballots more
prominently at the top of the page. If the budget has finished the final
voting stage without creating a poll, we don't show either the link or
the button because this feature can no longer be used.
We're also adding some texts indicating what this feature is about,
since it's probably one of the least understood features in CONSUL
(probably because the interface is very confusing... but that's a
different story).
Since now from the budget page we can access every feature related to
the budget, we can remove the "preview" action from the budgets index
table, since this feature isn't that useful for budgets once they're
published.
Now the budgets table doesn't take as much space as it used to, although
it's still too wide to be handled properly on devices with a small
screen.
Since managing investments is a very common action, with this link
administrators won't have to go back to the index page to manage
investments; they can access it from either the budgets index page or
the budget page.
Since now the links we've got on the budget page are similar to the ones
we've got in the index page table, we're styling them in a similar way.
We're also fixing a small typo en the investments path; it works exactly
the same way as it used to, but passing `budget` instead of `budget_id:
budget.id` is shorter and more consistent with what we do in other
places.
