These styles were broken in commit 2614de79c, since there we only
considered scenarios where the `tags` element is a list. In these forms, however, the `tags` element is a regular <div> tag.
Since we've changed the facebook and twitter login icons, it makes sense
to use the same icons in social share links.
Besides, using font-awesome simplifies the code and prevents problems
with screen readers announcing the value of the `content:` CSS property.
We were using the icon for google plus, which was confusing since google
plus no longer exists.
Note this change requires changing the font for these icons, since the
google icon is not present in the "icons" font. On the plus side, using
the font awesome icons we can simplify the code a little bit.
We had one exception running test suite [1]:
```
1) Commenting legislation questions Merged comment threads View
comments of annotations in an included range
Failure/Error: count: annotation.comments.roots.count) %>
ActionView::Template::Error:
PG::ProtocolViolation: ERROR: bind message supplies 0
parameters, but prepared statement "" requires 2
: SELECT COUNT(*) FROM "comments" WHERE "comments"."hidden_at" IS
NULL AND "comments"."commentable_id" = $1 AND
"comments"."commentable_type" = $2 AND "comments"."ancestry" IS NULL
```
Debugging shows this test was run right after the flaggable specs.
There's a chance these exceptions take place because the test is
accessing the database after the browser (chromedriver) process has
already accessed the database.
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 encouraging
good practices of system tests: test things from the user's point of
view.
[1] https://github.com/consul/consul/runs/1856245992
Using a button tag, it's possible for every user to "click" the element.
Besides, we don't need to call the `preventDefault` function, because
buttons with type "button" don't do anything by default.
The `proposal-show` HTML class was only used in this context to style
the whatsapp icon, which is now styled the same way as other social
share icons. The `proposal-show` class should be reserved for the actual
proposal show action.
We were using a custom icon because in the past social-share-button
didn't have support for whatsapp. But now that it does, we can remove
our custom icon.
Note we're using the `_app` suffix because that's the name of the icon
meant for mobile devices.
We've had a failure in one of our test suite runs [1]. A possible cause
could be an HTTP request taking place at the same time as an AJAX
request, with both trying to access the database at the same time.
We've had several similar issues in the past which have been fixed by
checking the AJAX request has finished before requesting another page,
so we're applying the same principle here.
[1] https://github.com/consul/consul/runs/1855207922
We were doing it manually, but Capybara offers an option which does the
exact same thing.
This way we also apply the NoJavascriptTagHelper ERB rule, which
reported one error in the `disable_animations_in_tests` partial.
The association `organization.user` returns `nil` when the user is
hidden.
This was discovered thanks to the `Style/AndOr` rule. We were using
`and` and `||` on the same line, which is confusing.
This way we can simplify the code and don't have to rely on `.try`
statements which are confusing and so we don't allow them in the
`Rails/SafeNavigation` Rubocop rule.
Note that in Ruby files this rule allows vertical alignment, but doesn't
seem to do the same in ERB. Since we only used vertical alignment in one
place, and that place also had an unneeded extra space on every aligned
line, I've decided to change the code in that place and follow the rule.
So now we remove duplication between .rubocop.yml and the rubocop rules
defined for erblint. Having the rules in two places led to some
mistakes, like renaming Layout/Tab to Layout/IndentationStyle in
`.rubocop.yml` but forgetting to do so in `.erb-lint.yml`.
This also means we can use the EnforcedStyle options for
Layout/SpaceInsideHashLiteralBraces in views as well.
We couldn't implement this feature earlier because it required Ruby 2.4
and due to incompatibilities between versions of erb_lint and versions
of rubocop.
There are some rules which do not apply to ERB files and so we're
disabling them.
* Layout/LineLength, Layout/TrailingEmptyLines and Lint/UselssAssignment
generate false positives
* Rails/OutputSafety is redundant since its functionality is already
covered by ERB Lint ErbSafety linter
Note this rule does still allow us to add new lines after opening tags;
it just makes sure that if we do, we also add it in closing tags.
Likewise, if we don't add it in the opening tag, it forces us not to add
it in the closing tag either.
I don't have a strong preference about either style; in these cases I've
chosen the latter because it seemed more common in our code.
This rule was added so the tag list wouldn't have an extra bottom
margin. However, the rule is already applied by the `.tags` selector
inside `.budget-investment` and it was conflicting with other lists
(goals and tags) we've added to thi investments index.
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 we check the given record or name is a relatable instance or class
to avoid trying to render goals for records which don't have a goals
association.
Note for now we are ignoring the case where we pass a controller_path
for an unsupported class (for example, `legislation/proposals` or
`budgets/headings`) because we never use it. We might need to revisit
this case in the future.
Co-Authored-By: Javi Martín <javim@elretirao.net>
