Note we're using the in-favor HTML class instead of the in_favor class
so we're consistent with our conventions for HTML classes and because we
use the in-favor class in similar places.
Also note the styles of the legislation process annotations/comments
buttons is now similar to the styles in the other sections. Previously,
the colors didn't have enough contrast and there was a very strange
margin between the "thumbs up" icon and the number of people agreeing
(that margin wasn't present between the "thumbs down" icon and the
number of people disagreeing).
As mentioned in commits 5311daadf and bb958daf0, using links combined
with JavaScript to generate POST requests to the server has a few
issues.
We're also improving the keyboard access. Previously, the links were
focusable and clickable with the keyboard. Now we're disabling the
buttons when voting isn't allowed.
Since these elements can no longer be focused, we're adding an element
with `tabindex="0"` so the "participation not allowed" message is shown,
like we do in most places.
Note we're slightly changing one test because now when hovering over the
button on Chrome, the "participation not allowed" text isn't shown; it's
only shown when hovering on the parts of the `div.ballot` element
outside the button. Since we're already rewriting the behavior of the
"participation not allowed" text in a different pull request, we aren't
going to fix this behavior.
This way we can make the view code a bit easier to read.
We're also changing the order of the conditions a little bit so we only
check for the presence of a current user once.
To make sure we aren't breaking anything with these changes, we're
adding some tests. We're also replacing one system test checking content
with a component test, since component tests are much faster.
Currently the translation:
"Notify me by email when someone comments on my proposals or debates"
It only refers to proposals and debates, but actually it also refers to budget
investments, topics and polls.
We add new method set_user_locale to render the page
with the user's preferred locale.
Note that we add a condition 'if params[:locale].blank?'
to recover the user's preferred locale. This is necessary
because it may be the case that the user does not have an
associated locale, and when execute '@user.locale' when
this value is 'nil', by default returns the default locale.
As we do not want this to happen and we want the locale we
receive as parameter to prevail in this case.
We modified the link that previously redirected us to the "My content"
page to redirect us to the new page for managing subscriptions.
We also adapted the existing generic text by adding a description of
the related notification.
We modified the link that previously redirected us to the "My content"
page to redirect us to the new page for managing subscriptions.
We also adapted the existing generic text by adding a description of
the related notification.
You can update the same "notifications" section that we allow you to
update in "my account".
This "subscriptions" section differs from the "my account" section
because we do not need to be logged in to update the status of the
notifications.
We forgot to remove it in commit f28a5cc49.
The generated HTML was invalid, with the error:
> Element meta is missing one or more of the following attributes:
> content, property.
It was a bit confusing to press the "hide" button and then see the user
listed as "blocked". Some moderators might think they accidentally
pressed the wrong button.
In the moderation section there's no clear indicator as to what the
"Hide" and "Block" buttons do and the difference between them.
Since we're using confirmation dialogs in all moderation actions except
these ones, we're adding them here as well, so the difference will
appear in the dialog.
This isn't a very good solution, though, since the confirmation dialog
comes after clicking the button and users have already been wondering
whether clicking that button will be the right choice. A better solution
would be making the purpose clear before the button is clicked, although
that's something we don't do anywhere in the admin/moderation sections.
The test "Action links remember the pagination setting and the filter"
was failing sometimes because it assumed the third user created was
going to appear in the third place, but that wasn't always the case.
So we're using the same order we use in the rest of the sections dealing
with hidden content.
In the past, whenever we hid users, we also hid their comments.
However, we've now implemented an action to hide users without hiding
their comments. In this case, we still want to show the comment, but we
weren't doing so.
We're continuing to replace links with buttons, for the reasons
explained in commit 5311daadf.
Since we're using the admin action component, we can also simplify the
logic handling the confirmation message.
In order to avoid duplicate IDs when generating buttons to block the
same author more than once in a page, we're including the record dom_id
in the ID of the button to block an author.
The `hide` action was calling the `block` method while the `soft_block`
action was calling the `hide` method.
Combined with the fact that we also have a `block` permission which is
used in `ModerateActions` the logic was hard to follow.
Note that in proposal notifications we're writing the call to
render the component in the same line as the <div class="reply">
definition in order to be able to use the `:empty` selector when the
component renders nothing. No browser matches whitespace with the
`:empty` selector, so we can't add newline characters inside the tag. A
more elegant solution would be extracting the proposal notification
actions to a component and only rendering it if the moderation actions
component is rendered.
Other than removing a redundant action, we're fixing two bugs when
blocking an author using the links in the public views:
* We were always redirecting to the debates index, even if we blocked
the author of a proposal or an investment
* We weren't showing any kind of success message
We're continuing to replace links with buttons, for the reasons
explained in commit 5311daadf.
We're also adding an ARIA label since on the same page there might be
several links to block different users.
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.
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
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.
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.
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.
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.
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.
