This way we can remove duplication and simplify the code in the view.
Note we're not using the "within" method in the tests to access a row,
because it doesn't seem to work in components tests when passing the
`text:` option.
In the past we were using some <div> tags surrounding table action
links in order to guarantee these links wouldn't be wider that their
cell's space and wouldn't expand over two lines.
However, while these links didn't expand over two lines, at certain
resolutions the width of their text exceeded the width of the links,
causing part of the text to be outside their borders.
This behavior was also inconsistent: some tables had these <div> tags,
and some tables didn't.
Since we've now introduced the table actions component, the code is more
consistent and we're getting rid of these <div> tags. So now we're again
facing the issue where links could expand over two lines.
Using a flex layout solves this issue and considerably improves the
layout at lower resolutions.
This partial was going to get too complex since in some places we've got
different texts, different URLs or different confirmation messages.
While we should probably try to be more consistent and that would make
the partial work in most cases, there'll always be some exceptions, and
using a partial (with, perhaps, some helper methods) will become messy
really quickly.
While Rails provides a lot of functionality by default, there's one
missing piece which is present in frameworks like Django or Phoenix: the
so-called "view models", or "components".
It isn't easy to extract methods in a standard Rails view/partial, since
extracting them to a helper will make them available to all views, and
so two helper methods can't have the same name. It's also hard to
organize the code in modules, and due to that it's hard to figure out
where a certain helper method is supposed to be called from.
Furthermore, object-oriented techniques like inheritance can't be
applied, and so in CONSUL customizing views is harder that customizing
models.
Components fix all these issues, and work the way Ruby objects usually
do.
Components are also a pattern whose popularity has increased a lot in
the last few years, with JavaScript frameworks like React using them
heavily. While React's components aren't exactly the same as the
components we're going to use, the concept is really similar.
I've always liked the idea of components. However, there wasn't a stable
gem we could safely use. The most popular gem (cells) hasn't been
maintained for years, and we have to be very careful choosing which gems
CONSUL should depend on.
The view_component gem is maintained by GitHub, which is as a guarantee
of future maintenance as it can be (not counting the Rails core team),
and its usage started growing after RailsConf 2019. While that's
certainly not a huge amount of time, it's not that we're using an
experimental gem either.
There's currently a conflict between view_component and wicked_pdf.
We're adding a monkey-patch with the fix until it's merged in
wicked_pdf.
We can find the booth through the booth assignment, so we don't need to
pass it in the URL.
Since the parameter is in the URL and not sent through a form, we can
also use `params[:poll_id]` directly, and so we can reuse the
`load_poll` method.
We were manually adding forgery protection to all our controllers, but
in Rails 5.2 there's an option (enabled by default for new applications)
which adds this protection to all controllers.
Rails 5.2 is raising a warning in some places:
DEPRECATION WARNING: Dangerous query method (method whose arguments are
used as raw SQL) called with non-attribute argument(s). Non-attribute
arguments will be disallowed in Rails 6.0. This method should not be
called with user-provided values, such as request parameters or model
attributes. Known-safe values can be passed by wrapping them in
Arel.sql().
IMHO this warning is simply wrong, since we're using known PostgreSQL
functions like LOWER() or RANDOM(). AFAIK this code works without warnings
in Rails 6.0 [1][2]
However, since the warning is annoying, we need to take measures so our
logs are clean.
[1] https://github.com/rails/rails/commit/6c82b6c99d
[2] https://github.com/rails/rails/commit/64d8c54e16
Instead of having a header with a bottom margin followed by an element
with a negative margin, it makes more sense to have no margin on either
element.
On high-resolution screens where neither the menu nor the main content
were filling the screen, there was a blank space at the bottom which
looked weird.
The <main> tag was including the navigation, and now we use the same
flex layout, making it more accessible for mobile phone users.
I'm not sure the <main> tag should actually include the account info and
the flash message. I'm keeping it like this in order to keep the layout
the way it was.
While Foundations's off-canvas menu allows us to forget about writing
CSS, it also leads to complicated HTML.
Ideally Foundation would provide an easy way to simplify what we're
doing, but I haven't found anything in the documentation.
We could simplify the HTML a bit more if we used a CSS grid layout
instead of a flex one, but old browsers have better support for the
latter.
Note we're using `breakpoint(medium)` so we can group the CSS for small
screens and follow SCSS-Lint rules at the same time.
Also note behavior of the main area when the menu appears on small
screens is slightly different: it doesn't move the main content to the
right. I've done it this way so we don't have any overflow issues,
unlike the previous version.
There's a small issue using a label and a checkbox to enable/disable the
menu: sighted keyboard users with a small screen might not be able to
enable the menu. So we're adding the `:focus-within` pseudoclass so the
menu can be normally navigated using the keyboard. Even if old browsers
don't support this pseudoclass, we believe the probability of a sighted
user using a small screen, navigating with the keyboard and using an old
browser is really low, particularly in the admin area.
We're also adding the `aria-hidden` attribute on the label, since the
menu is never hidden for screen readers and so having a control to show
it could be confusing. Since the label is not focusable, we're complying
with the fourth ARIA rule:
> Do not use role="presentation" or aria-hidden="true" on a focusable
> element .
>
> Using either of these on a focusable element will result in some users
> focusing on 'nothing'.
In commit 74083df1 we added the possibility to assign administrators and
valuators to budgets, so they would only manage the budgets they're
assigned to.
However, when filtering projects, we were still showing all
administrators and valuators as options to filter investments. It makes
more sense to only show the valuators and administrators assigned to the
current budget.
Note this change only affects the view, and so malicious users could
technically send any other administrator or valuator ID. In this case,
they would get empty results since those administrators/valuators
wouldn't have any investments assigned, so taking this case into account
is not necessary.
We had helper methods all over the place which were only used in one
view. Since we're going to change some of them to use the budget as a
parameter, they don't belong in those helpers anymore.
Note the method `budget_heading_select_options` is used in more places,
so we're keeping it where it was.
It was removed in commit 128a8164 because we hadn't reviewed it nor
tested it properly. We're now adding it again, fixing the issues we've
found while reviewing.
This way we can simplify the HTML and easily apply font awesome icons to
any element.
Note the mixin uses `extend`, which we generally try to avoid. It's OK
in this case, since `fa-` classes only have one rule, affecting the
content of its `::before` pseudo-element. Unfortunately we can't use
`include fa-content($fa-var-#{$icon})` because it's not valid SCSS. We
could make the mixin accept an icon instead of an icon name, and call it
using `has-fa-icon(r, $fa-var-plus-square)`. However, IMHO that would
make the code a bit more complex with no real benefit.
Legislation Processes created through the admin form were getting the default color.
However, Legislation processes created by other means (like the `db:dev_seed` rake task) were not getting these default values.
This feature was originally implemented when we were using Rails 4.
With Rails 5, we can provide default values to all new Legislation processes
and simplify the code at the same time thanks to its `attribute` method.
Related commit:
https://github.com/consul/consul/pull/4080/commits/0b83be6
According to the jQuery upgrade guide:
> It is almost always a mistake to use .removeAttr("checked") on a DOM
> element. The only time it might be useful is if the DOM is later going
> to be serialized back to an HTML string. In all other cases,
> .prop("checked", false) should be used instead.
It worked differently after upgrading to jQuery 3. According to the
jQuery upgrade guide:
> It is almost always a mistake to use .removeAttr("checked") on a DOM
> element. The only time it might be useful is if the DOM is later going
> to be serialized back to an HTML string. In all other cases,
> .prop("checked", false) should be used instead.
We've had to add a couple of hacks in order to make jQuery UI datepicker
work with Turbolinks, and one of our tests is failing because the
datepicker changes its height when changing from a month with 5 weeks to
a month with 6 weeks.
We could add a workaround so the test still passes (jQuery UI doesn't
provide a configuration option to always displays 6 weeks in the
datepicker), but I think it's easier to just use the HTML5 native date
input field, which also allows us to simplify the code a bit and IMHO it
improves the user experience, particularly when using mobile phones.
Since date fields are not supported in Safari and Internet Explorer,
we're still using the jQuery UI datepicker on those browsers (and on any
other browser not supporting date fields).
Due to these changes, we're moving the tests checking datepicker's
behaviour to the dashboard. I've choosing not to change the public pages
because I'm not 100% sure everybody would like this change (some people
prefer the datepicker because we can configure the way it looks).
When Foundation initializes a page that has any sticky element, it
loads a window scroll listener into window object to handle the sticky
element positioning when scrolling. This works great until user moves
to a page without sticky elements and the window listeners remain
attached to the window object on this new page too when there is no
need to run the scrollListener and there is no sticky elements so the
window scroll listener cannot find the sticky object on that page a lot
of errors are thrown when user scrolls.
With this approach we are destroying sticky elements before leaving
the page which also remove the Sticky scrollListener from the window
object.
I do not know how to write a test to demonstrate this fix, but at least
there is some steps to reproduce this behavior:
0. Undo this commit
1. Go to any proposal page
2. Click on any link (with Turbolinks enabled)
3. Scroll the page
4. Check the console log. Yo will find as error occurrences as pixels you scrolled.
