While trying to add the target="_blank" to this link I noticed that this attribute
no longer works in some places in the application, such as the terms and
conditions link in the sign_up page.
For the time being I think we can resolve it this way in this case and deal with
this issue in a separate PR.
In this page we will render a list of clickable Goals icons that will show their
targets and related local targets
Co-authored-by: Senen <senenrodero@gmail.com>
This component was rendered on different pages so there were no conflicts
with static id's.
Now in the SDG help page we are going to render them all at once, so we
convert the static identifiers to dynamic.
Previously the draft mode was a phase of the PB, but that had some
limitations.
Now the phase drafting disappears and therefore the PB can have the
status published or not published (in draft mode).
That will give more flexibility in order to navigate through the
different phases and see how it looks for administrators before
publishing the PB and everybody can see.
By default, the PB is always created in draft mode, so it gives you
the flexibility to adjust and modify anything before publishing it.
We were displaying the total number of notifications with a message "You
have N unread notifications", but were using the total number of
notifications instead of the unread ones.
Other than simplifying the view, we can write tests using `click_link`,
which makes the tests more robust. Clicking the `.icon-notification`
element was causing some tests to fail when defining a window height of
750 pixels in the `admin_budgets` branch.
Hopefully now it's a bit more obvious that SDGs can be selected by
clicking on them and that the field to select goals and the field to
select targets/goals are related (since they're now part of the same
fieldset).
We were using list items with the checkbox role. This is probably
confusing since list items have a listitem role, and so we were
basically using a list with no listitem.
We could add a `<span role="checkbox">` tag inside the list item, but
using real checkboxes is probably easier. We're also adding a test to
verify the checkboxes native behavior is compatible with our code.
Note we're using the "enter" key to toggle the "checked" status of the
SDG. This is probably not intuitive for screen reader users who might
try to submit the form using the "enter" key after selecting a goal.
However, the alternative would be even less intuitive for sighted
keyboard users, since for them these icons look like links or buttons
and they would accidentally submit the form when trying to select a
goal.
Since we haven't come up with a better interface yet, for now we're
following the principle of least damage; we consider submitting the form
against a user's will is less annoying than forcing users to move to a
different field before being able to submit the form.
Also note we can't write `check` in the tests because Capybara will try
to click the checkbox, which is hidden by the image in the label.
So now we've got a component receiving records (goals or targets) and a
related model (Debate, Proposal, ...), with optionally a link to see
more tags.
This way we simplify some logic since the `TagList` classes were dealing
with too many cases (a record is passed, a class name is passed, a limit
is passed), ... Now `TagList` only deal with the natural `TagList` case,
which is listing the tags for a record. The case where a class name is
passed is used in the `TagCloud` class.
Now the tag list can render tags with or without links, so we need
to adapt the styles slightly.
We want to use the same text color for tags without links.
The hover style is only needed when using tags with links.
Note we're using both the `hidden` and `disabled` properties to
guarantee compatibility with user agents which might still display the
option even when using the `hidden` attribute or hiding it with
`display: none`. We could also use `hide()` and `show()` instead of the
`hidden` property, but since we're using the `disabled` property, I
thought the code would be easier to read if we used properties in both
cases.
Also note users will no longer be able to get, let's say, debates which
are related to goal 1 and target 2.1. We think this use case is highly
unlikely and there's no need to take it into account.
We're going to add some JavaScript which affect this component, and IMHO
it will be easier to know the JavaScript affects this form if both have
their own separate file.
This way we'll be able to add targets as well. Besides, having two
classes in the CSS selector will allows to overwrite styles such as
`.debate-show ul li`.
On the other hand, we need to add a stylesheet for the filters as well.
In the spec we added in system/sdg/goals_spec.rb we couldn't use
either click_link or find_link, because the link to show/hide the
long description doesn't have the href attribute.
Having the date at the beginning makes it less weird to select a custom
date now that we don't have enough space to display the "from" and "to"
date selectors in different columns.
