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.
This way we generate the same HTML as we generate everywhere where we
manually generate lists of links. Having a blank space betwwen tags
results in a space being introduced when the elements are displayed
inline (or with `inline-block`).
So in places where we don't want that space between the elements we have
to use a flex layout.
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.
This way we won't have to add the `inline-block` and `no-bullet` classes
to other elements and we can define the styles in one place.
Note we're using the `ul.tags` selector instead of just `.tags` to avoid
conflicts with a `div.tags` selector which is used to select tags in a
form. Renaming the selector to `.tag-list` would be better, but we
aren't doing so because it would break custom stylesheets using that
selector.
Also note we're keeping the %tags placeholder selector in `.tags`
selector in the participation.scss file. This is so styles are not
overwritten by selectors like `.debate-show ul li`, which has the same
specifity as `ul.tags li`.
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.
This is similar to what we do with investments, which belong to a heading
but also belong to a budget. In our case, the reason is we've been asked
to add local targets which belong to a goal but are not related to any
existing target.
Even though we're not implementing that case right now, we're adding the
relation so we don't have to add data migrations in the future.
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.
While running our test suite, we were getting an exception sometimes:
```
Proposal Notifications In-app notifications from the proposal's author Followers should receive a notification
Failure/Error: notification_for_user2 = Notification.find_by(user: user2)
ActiveRecord::StatementInvalid:
PG::ProtocolViolation: ERROR: bind message supplies 0 parameters, but prepared statement "" requires 2
: SELECT "notifications".* FROM "notifications" WHERE "notifications"."user_id" = $1 LIMIT $2
# ./spec/system/proposal_notifications_spec.rb:268
```
Sometimes we were getting a similar exception in a different test:
```
Commenting legislation questions Merged comment threads Reply on a multiple annotation thread and display it in the single annotation thread
And sometimes we were getting a different one:
Failure/Error: annotation.comments.roots.sort_by_most_voted.limit(Legislation::Annotation::COMMENTS_PAGE_SIZE).each do |comment|
ActionView::Template::Error:
PG::ProtocolViolation: ERROR: bind message supplies 0 parameters, but prepared statement "" requires 3
```
My best (wild) guess is these exceptions might take place because the
test is accessing the database and at the same time the browser
(chromedriver) process is accessing the database, with code like:
```
find(".icon-notification").click
notification_for_user2 = Notification.find_by(user: user2)
```
Or:
```
first(:css, ".annotator-hl").click
(...)
comment = annotation1.comments.first
click_link "Reply"
```
This behavior happened sometimes while using transactional fixtures and
a shared database connection with feature specs (before system specs
were introduced in Rails 5.1) when some queries were triggered from the
test after the browser process was started.
So we're avoiding the situation by writing the tests from the user's
point of view. This is just an attempt at fixing the issue; I don't know
whether these changes will fix it since I've only seen this exception on
Github Actions (never on my machine). Worst case scenario, we're still
improving the tests legibililty.
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"...
Add spec which is fixed with this commit.
In the `sTagsArea` zone there are two elements with the same `data-val`:
the `<span class="amsify-select-tag>` containing the selected tag and
the `<li class="amsify-list-item" data-val="1">` containing the
suggested tag.
This means every time we call `removeTag`, the `removeTagByItem`
function is called twice, and might remove extra items.
Suggested PR:
c8765a6915
