Defining a behavior on hover means making it different for people using
a keyboard or a touchscreen (most of the population, nowadays).
In this case, we had an accessibility issue where the message wouldn't
disappear once it appeared. That meant that, after tabbing through all
the links and buttons in, for instance, the debates index, the page
would be filled with "participation not allowed" messages, and in order
to see the information about how many people have voted, reloading the
page was required.
For touchscreen users the behavior was similar to what we get on hover,
although we've found some inconsistencies when trying to support several
elements on the same page.
We think in proposals it makes sense to hide the "support" button when
users click on it, and the same applies to the buttonsto support and
vote investment projects. However, we aren't hiding the buttons to
agree/disagree with a debate in order to keep the information about the
current number of people agreeing and disagreeing visible.
Note we're removing some support spec methods because after these
changes the duplication isn't as obvious as it was in the past.
We were using the same logic six times regarding when we should show a
"participation not allowed" message. Since we're going to change the
current behavior, we're unifying the logic in one place so the changes
will be easier.
Hovering over the votes showed a "participation not allowed" message
which was annoying when scrolling with the browser or simply moving the
mouse around the page. Furthermore, it hid the information about the
number of votes, links to show/collapse replies, ...
We're planning to change the behavior of all the "participation not
allowed" messages in order to show them on click instead of showing them
on hover (just like it's done on touchscreens). In the case of comments,
supports, however, there's very limited space in the part showing the
number of supports for comments, so adding this message without breaking
the layout is challenging.
So, for now, we're simply redirecting unauthenticated users to the login
page. If find an easy way to implement a better user interface in the
future to display the "participation not allowed" message, we might
change this behaviour.
This message is only shown in the `show` action, so it's shown at most
once in the whole page, so it doesn't take up too much space and it
isn't as overwhelming as if we were showing it on the index page, once
per debate.
We're only showing it when there are closed options, though, since
there's already a message to sign in to comment when the question
accepts open answers.
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.
Using the `flex-with-gap` mixin we avoid the left margin in the second
element when the screen space isn't wide enough to show both buttons.
Setting the margins with CSS also allows as to simplify the view and
makes it easier to customize styles.
Having buttons (previously links) with the text "I agree 75%" is
confusing; people might believe they're saying they only partially agree
with the content. Besides, the results percentages is a different piece
of information which shouldn't be related to whether one person
agrees/disagrees with the content.
This problem might be solved for people using screen readers since we
added the aria-label attribute. However, for sighted keyboard users, the
percentage was being outlined on focus as part of the button, which
might be confusing.
Note we're using the `budgets.investments.investment.add_label` and
`budgets.ballots.show.remove_label` internationalization keys so they're
consistent with the `budgets.investments.investment.add` and
`budgets.ballots.show.remove` keys which were already present. We aren't
unifying these keys in order to keep existing translations.
This way blind screen reader users will know which proposal they're
supporting. In a list of proposals, context might not be clear when a
link saying "Support" or "Support this proposal" is announced, but a
link saying "Support Create a monthly transport ticket" is less
ambiguous.
Just like we did with investments in commit de436e33a, we're keeping the
title attribute because when visiting a proposal page, the connection
between the "Support" link and the proposal is not as clear as it is in
the proposals index page, so it might not be clear what you're
supporting.
We were using the same code to render links to agree and disagree, so we
can extract a new component for this code.
We're also adding component tests to make it easier to test whether
we're breaking anything while refactoring, although the code is probably
already covered by system tests.
Since the votes mixin was only used in one place, we're removing it and
moving most of its code to a new CSS file for the shared component.
Very similar code is present in the `votes.js` file. Since the only
elements with the `js-participation-not-allowed` class also matched the
`div.supports div.participation-not-allowed` selector, for these
elements the events were executed twice.
So we can get rid of the `js-participation` class alongside all the
JavaScript code referencing it.
When there isn't a current user, the links can't be clicked, so there's
no real point in them being links.
When there's a current user and they cannot vote (for example, an
organization), having a link/button to an action they can't perform
isn't that useful IMHO. They get a message saying they aren't allowed to
vote but the message doesn't say why. However, in this case, many people
might try to click/touch the link/button and will wonder why nothing
happens, so we'll revisit this issue when we change the way we display
the "participation not allowed" messages.
Now the behavior is more similar to the one we get when voting
proposals/debates.
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.
The action and the views were almost identical, with the supports
progress and the HTML classes of the success message element being the
only exceptions; we can use CSS for the styles instead.
Just like we did in commit 0214184b2d for investments, we're removing
some possible optimizations (we don't have any benchmarks proving they
affect performance at all) in order to simplify the code.
The investement votes component `delegate` code was accidentally left
but isn't used since commit 0214184b2, so we're removing it now that
we're removing the `voted_for?` helper method.
The `legislation_proposals#index` action was never used because it used
the same URL as `legislation_processes#proposals`.
In commit 702bfec24 we removed the view, but we forgot to remove the
controller action, the route, and some partials which were rendered from
the index view.
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.
The user can access this page without being logged in.
We identify the user through the "subscriptions_token" parameter and
show a list of the notifications that can be enable/disable.
We will return a 404 error in case someone accesses the page with a
non-existent token.
We also control the case that some anonymous user tries to access the
page without any token, by returning the CanCan::AccessDenied exception.
Giving any user a direct link to edit another user's account settings doesn't seem like a
great idea. Instead we'll generate a random secure hash string to help keep things
more secure. We'll store these hashes on each user so that we have a way to find
them during this public query. To do this we need to add a column to the user table.
In commit 905ac48bb we mentioned:
> Since we don't use `asset_path` to reference assets in the public
> folder, we can safely disable the `unknown_asset_fallback` option.
However, `asset_path` is used by the wicked_pdf gem when calling the
`wicked_pdf_stylesheet_link_tag` method. This method also checks the CSS
files, searching for `url()` calls and converting any relative URLs
referenced there to absolute URLs.
However, when compiling assets on production, our `application.css` file
contains the following line imported from Leaflet which says:
```
behavior: url(#default#VML);
```
When passing this URL to `asset_path` (which is something the wicked_pdf
gem does automatically), it doesn't find the URL, and so this call
crashes unless we enable then `unknown_asset_fallback` option.
Since the dashboard poster is a feature we might remove in the future,
we're avoiding changing a Rails global configuration just for this
feature. So, instead of enabling the `unknown_asset_fallback` option,
we're changing the `poster.pdf` view so it doesn't load all the CSS of
the application but only the CSS it needs.
Note we aren't adding a test case because this bug is only present on
production environments when assets have been precompiled.
