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.
To make it easier to add the component to the front pages forms and
avoid introducing redundant classes we add the necessary padding
(@include grid-column-gutter) to make it behave like the rest of the form
fields.
Note that for the sdg management section we set this value to 0.
Render the tags under the input. This way the input is not moved down
when a tag is added.
Render icons under the label. As you can add tags by clicking on the icons,
in this way the input is more related to the icons.
Add "display_text" to allow customize the text that we want render on tag.
For Goals we render "SDG1", "SDG2"..
For Targets we render the code "1.1", "1.A"...
- When we click on an icon we add a new tag with the Goal related to the input or
we remove the tag when that label already exists.
- Manage goals icons status when add or remove related targets:
Whenever there is a tag related to Goal, either the Goal itself or a Target, the icon
will be "checked".
When there is no related Goal or Target it will no longer be marked as checked.
This will allow autocomplete for the loaded values in suggestions settings.
We remove commas on tag to allow to jquery.amsify.suggestag.js use comma
as delimiter.
This component allows you to add Goals and Targets in a single
input to relate it to any resource.
We use the new added library to render them as tags.
Now the banner component accepts either a banner or a section and loads
the banner if it's a section, so we don't have to add the `@banners`
variable in several controllers.
We have three filters: "pending", "all" and "reviewed". Where "pending"
is the default one.
Now we are rendering the `shared/_filter_subnav` partial we need to stub
helper methods defined at the controller and the helper methods that
rely on the request parameters to test the component.
These cards will be displayed in the SDG homepage.
Note there seems to be a strange behavior in cancancan. If we define
these rules:
can :manage, Widget::Card, page_type: "SDG::Phase"
can :manage, Widget::Card
The expected behavior is the first rule will always be ignored because
the second one overwrites it. However, when creating a new card with
`load_and_authorize_resource` will automatically add `page_type:
"SDG::Phase"`.
Similarly, if we do something like:
can :manage, Widget::Card, id: 3
can :manage, Widget::Card
Then the new card will have `3` as an ID.
Maybe upgrading cancancan solves the issue; we haven't tried it. For now
we're defining a different rule when creating widget cards.
