This link used to open in a new window, and we accidentally changed that
behavior while refactoring it in commit c2710de5f.
Since we're adding a test for this case, and the Proposals::NewComponent
class is similar, we're adding a test for that class too. In the case of
proposals, we need to sign in a user because the proposals form contains
fields to attach image, that currently rely on a user being signed in.
The `use_helpers` method was added in ViewComponent 3.8.0, and it's
included by default in all components since version 3.11.0.
Note we sometimes delegated the `can?` method to the controller instead
of the helpers, for no particularly reason. We're unifying that code as
well.
Before this change, two important things depend on the format of each key,
where to render it in the administration panel and which kind of interface
to use for each setting. Following this strategy led us to a very complex
code, very difficult to maintain or modify. So, we do not want to depend
on the setting key structure anymore to decide how or where to render each
setting.
With this commit, we get rid of the key format-based rules. Now we render
each setting explicitly passing to it the type and the tab where it belongs.
Instead of using a setting nested param `setting[:tab]`. We only need
the tab param when rendering settings in the administration section.
This change will make it easier rendering the correct tab after
updating settings.
This will help search engines know these links point to external sites
and it'll make it possible to style these links using the
`[rel~=external]` selector. AFAIK, assistive techonologies don't use
this attribute to notify people about external links, though.
This is a funny one, because we were accidentally opening them in the
same window without intending to do so since commit 928312e21, since the
`sanitize` method removes the `target` attribute. So the test we're
adding already passed without these changes.
Just like we're doing with other external links.
We already mention that it's an external video, so there's no need to
explicitly indicate it in the link.
As mentioned in earlier commits, opening external links in a new
tab/window results in usability and accessibility issues.
Since these links are usually at the top or bottom of the page and
contain icons of well-known sites, IMHO there's no need to even notify
people that these are external links.
Since we're no longer using the `shared.target_blank` translation inside
a sentence, we can remove the space and parenthesis in the translations.
In the admin section, when clicking on a link that leads to a page in
the public area, sometimes the page was opened in the same window and
sometimes it would open in a new window, with no clear criteria
regarding when either scenario would take place.
This was really confusing, so now we're more consistent and open
(almost) every link in the same window. The main reason behind it is
simple: if we add `target: _blank`, people who want to open those links
in the same window can no longer do so, so we're taking control away
from them. However, if we don't add this attribute, people can choose
whether to open the link on the same tab or to open it on a new one,
since all browsers implement a method to do so.
More reasons behind this decision can be found in "Opening Links in New
Browser Windows and Tabs" [1].
We're keeping some exceptions, though:
* Opening the link to edit an investment on the same tab would result in
losing all the investment filters already applied when searching for
investments, so until we implement a way to keep these filters, we're
also opening the link to edit an investment in a new tab
* For now, we're also opening links to download files in a new window;
we'll deal with this case in the future
[1] https://www.nngroup.com/articles/new-browser-windows-and-tabs/
Most screen readers don't notify when a link is about to open in a new
window [1], so we're indicating it, like we were already doing in most
places with similar links.
We could also add a visual indicator, but since links inside labels
already have accessibility issues, giving more attention to these links
might make matters worse.
[1] https://www.powermapper.com/tests/screen-readers/navigation/a-target-blank/
IMHO the best solution would be to completely remove this checkbox on
forms that require registration. Other than the fact that people have
already agreed with these terms when registering (although I guess these
terms might have changed since then) and that approximately 0% of the
population will read the conditions every time they agree with them,
there's the fact that these links are inside a label and people might
accidentally click on them while trying to click on the label in order
to check the checkbox.
I guess the idea is that these conditions might have changed since the
moment people registered. In a fair world, checking "I agree" would have
no legal meaning because it's unreasonable to expect that people will
read these conditions every time they fill in a form, so whatever we're
trying to do here would be pointless.
But, since I'm not sure about the legal implications of removing this
field in a world where you have to inform people that websites requiring
identification use cookies, for now the field will stay where it is.
In some places, we were using `blank` instead of `_blank`. Most browsers
treat `blank` like `_blank`, though, so most people didn't experience
any difference.
In another place, we were incorrectly passing the `target` option inside
an `options:` hash, resulting in invalid HTML.
Quoting usability experts Jakob Nielsen and Anna Kaley [1]:
> [Opening PDF files in new tabs] is problematic, because it assumes
> users will always do the exact same things with certain file formats,
> which isn’t always the case.
There are many examples of this situation. For example, some people
(myself included) configure their browser so it downloads PDF files
instead of opening them in the browser. In this situation, a new tab is
opened, a blank page is displayed, the file is downloaded, and then
either the tab is closed or the blank page needs to be manually closed.
The end result is really annoying.
Other situations include people who use a mobile phone browser, where
navigating through tabs is generally much harder than doing so on a
desktop browser.
But IMHO the most important point is: every browser already provides a
way to open "regular" links in a new tab, so people can choose what to
do, but if we decide to open the link in a new tab, we take control away
from them, and people who'd like to open the link in the same tab might
feel frustrated.
In these cases, the links either say "download" or include the word
"PDF", so people know in advance that they're going to download/open a
PDF file, and so we're giving them information and, by removing the
`target` attribute, we're giving them control over their browser so they
can choose what's convenient for them.
[1] https://www.nngroup.com/articles/new-browser-windows-and-tabs
We were displaying documents in five places, and in five different ways.
Sometimes with the metadata in parenthesis after the title, sometimes
with the metadata below the title, sometimes without metadata, sometimes
with an icon in front of the document, and sometimes with a separate
link to download the file.
So we're now displaying the same thing everywhere. Not sure whether this
is the best solution, but at least it's consistent.
We aren't unifying the way we display a list of documents, though, since
different sections look pretty different and I'm not sure whether the
same style would look well everywhere.
Note that we're renaming the `document` HTML class in the documents
table to `document-row` so the styles for the `document` class don't
apply here.
This way it'll be easier to change them.
Note that there were two `.document-link` elements which aren't part of
a `.documents` element. We're renaming the HTML class of the link in
investments because it didn't contain links to download documents and
are slightly duplicating the CSS in the poll answer documents in order
to keep the `word-wrap` property.
Using the `document` or `documents` classes meant styles defined for the
public list of documents conflict with these ones.
So now we're using HTML classes that match the name of the Ruby
component classes, as we usually do.
We were adding <div> tags with the `images` or `documents` HTML class
prettly much every time we rendered a NestedComponent. We're now
including the HTML class inside the component, as we usually do.
We're also rendering the nested components directly, since it's been a
while since the partials were changed to simply render the components.
There's a link next to it that does the exact same thing and includes
the word "download", which was confusing in some cases since people
might think that links with different texts lead to different pages.
In order to comply with the security measure for the
ENS: "[op.acc.5.r5.2] The user shall be informed of
the last access made with his identity".
We have added a new secret to display the last
access made to the user on the "My account" page.
This way we make it easier to modify.
Note that, since the title of the page is "Administration" and it's in
the "Admin" section, we're adding an option to the `header` method in
order to avoid having a confusing title like "Administration - Admin".
Also note that, by removing the `title` HTML class, we avoid inheriting
styles from the `dashboard.scss` stylesheet, and now the heading is
displayed in the position it was meant to.
Finally, the concept of using a `main-class` for the current page comes
from a branch (currently in development) which will replace the <div>
tag with the `admin-content` class with a `main` tag.
