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.
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
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).
We were using a <label> tag with no associated field where a <legend>
tag was more appropriate. With a fieldset, we also make it obvious these
fields are related.
Rails automatically disables buttons when submitting a form. This works
fine most of the time: for AJAX requests, it enables them again after
the request is complete, and for non-AJAX requests, the button is
replaced by a new element when the new page loads.
However, there's an exception. When a request returns data so users can
download a fire, the request is not an AJAX one and the button is not
replaced. So users are left with a disabled button they can no longer
click.
So in this case, we aren't disabling the button after a user clicks it.
After updating foundation-rails in commit 58071fd6, the orbit slider
stopped working properly. That's because the `.orbit-slide` elements now
use a `position: absolute` rule, and so our rule for `.orbit-container`
elements making their height 100% (which we added in order to be able to
add images with different heights) makes them have a height of 0px,
since now the `.orbit-slide` elements are not part of the document flow
anymore.
Making the `.orbit-slide` elements have relative position fixes this
issue, but introduces a different one, producing a really bad-looking
animation when changing a slide.
So we're disabling the animation as well in order to avoid this jump.
This change also fixes another issue introduced in commit 58071fd6 which
caused slide controls to stop working when changing slides back and
forth.
Banners created through the admin form were getting the default color.
However, banners 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 banners and
simplify the code at the same time thanks to its `attribute` method.
Now, when creating a new banner, instead of getting a blank space, we
get an empty line with the banner's default background color, which most
users won't know what it's about until they fill in the banner's title.
So we're not displaying the content of the banner when it's empty,
thanks to the `:empty` CSS pseudoclass.
We need to use page body event delegation so it will work with any
element even with the ones added through ajax, in this case the
annotation comments box form. By doing this way we do not need
this code on the server response anymore.
Furthermore JS events defined at ajax responses are not part of
application javascript and are lost when restoring a page from
browser cache, you can try to apply the same event delegation
technique to the `erb` file and it wont work just because events
added dinamically are not treated the same than `application.js`
code.
To reproduce the error:
1. Load an annotatable draft version
2. Move to any other page
3. Go back
Now "Publish comment" button wont work.
Note we're using a new sanitizer. Ideally we'd reuse the
`AdminWYSIWYGSanitizer`, but then code that would be correctly shown by
markdown-it (like the <h1> tag) wouldn't be shown on the web, which is
confusing. Ideally we would configure markdown-it to only allow the tags
present in the `AdminWYSIWYGSanitizer` and provide some kind of help
showing which tags are allowed.
This is the reason why this feature was implemented in the first
place: it's easy to open the editor, make some changes, close it, and
continue without realizing the changes have not been saved.
In the rest of the forms, this functionality is quite lacking. For
starters, some forms warn if there are unsaved changes, while some forms
don't, which is highly inconsistent and disorients users.
Furthermore, we were having problems with this feature after upgrading
Turbolinks, particularly in forms using CKEditor. In these cases, a lot
of hacking needs to be done in order to make this feature work properly,
since CKEditor adds some formatting automatically, and if this is done
after the form is serialized, we'll get some unexpected behavior. On the
other hand, comparing the value of a textarea against its `defaultValue`
property will work on every edge case, including using the browser's
back button or reloading the page.
Finally, users are used to the way web forms work, and aren't used to be
asked for confirmation when they change their mind and decide to leave
the page without saving the changes. Asking them for confirmation will
be annoying in most cases. Besides that, if they accidentally leave the
page, they can use the browser's back button and they'll recover the
unsaved changes.
It's true this won't happen it they accidentally close the browser's
window, but our WatchFormChanges functionality didn't work in this case
either. Using the "beforeunload" event adds more problems than it
solves, since it doesn't support custom messages (or, to be more
precise, modern browsers ignore custom messages), and it doesn't get
along with turbolinks.
Co-Authored-By: Senén Rodero Rodríguez <senenrodero@gmail.com>
We didn't upgrade Turbolinks when we upgraded to Rails 5 so we didn't
upgrade too many things at the same time, and postponed it... until now
:).
Note upgrading Turbolinks fixes an issue with foundation's sticky when
using the browser's back and forward buttons. We're adding tests for
these scenarios.
Co-authored-by: Senén Rodero Rodríguez <senenrodero@gmail.com>
TableSortable and Sortable javascripts were using the same CSS
class name to define completely different and separated
behaviours causing unexpected errors. Now `sortable.js` script
will use `.sortable` class and `table_sortable.js` will use
`.table-sortable` instead.
We were displaying two progress bars for the same thing, and hiding one
of them.
Displaying just one of them and readjusting the styles accordingly is a
bit more intuitive IMHO.
We're also getting the text inside the progress bar out of it; its
purpose inside an element with the `progressbar` role is to provide the
same information as the progress bar (which we aren't exactly doing,
although it could be argued that we do), and in order to be accessible
we should provide the same text in the `aria-valuetext` field, which we
aren't doing. This also simplifies our CSS, which was working because we
defined a padding which covered the height of the hidden extra progress
bar and would have needed quite a few changes if we kept just one
progress bar with text inside it. We can also remove a few CSS rules
which we added to override foundation's rules for the
`progress-meter-text` class.
We were setting it to 0, and so screen reader users might be confused by
it.
The easiest way to reuse the code and using it for both this attribute
and the width of the progress bar is to move this method to the voting
style, just like the other methods used in this view.
Note the progressbar ARIA role might not be right, since this isn't a
task which is "progressing", but an indicator of the amount spent and
amount available, which is exactly what the <meter> HTML5 tag was
designed for.
We might use a <meter> tag in the future. For now, I'm leaving it as it
is because I'm not certain about how well <meter> is supported in
accessibility tools, and because it's definitely not supported in
Internet Explorer 11, which we haven't officially dropped support for.
We were rendering an individual ballot, and then rendering all ballots
(including the already rendered one). So we can skip the first part, as
pointed out by microweb10 in the comments of pull request 3036.
We're passing the amount as a paramenter to the "remaining" text, so it
makes sense to pass it to the "amount spent" text as well.
Here we're also changing the I18n key to the text saying users can
change their vote, so it's easier to note the text is about changing
their vote, and not about the projects they have voted so far.
The `refresh_ballots` partial ignores the `investment` parameter
completely; instead, it iterates over the investments in the
`@investments` instance variable.
We were writing the same code twice, with the only difference being the
text "Sign up" in the sign_up action, and "Sign in" in the sign_in
action.
Note we're renaming the `omniauth.info_*` I18n keys so we don't need to
add new exceptions to the `ignore_unused` list, and so it's consistent
with all the other keys under the `omniauth` key.
The main obstacle to extract this partial was probably the paths for the
flag and unflag actions.
Now that we use Rails 5.1 `resolve` method to handle nested resources,
we can use `polymorphic_path`.
Also note the code is a bit ugly because comments render a divider. We
should probably use a CSS border instead.
Co-Authored-By: taitus <sebastia.roig@gmail.com>
We were treating legislation proposals as if they were proposals,
omitting the "legislation" namespace, and so we were flagging/unflagging
proposals when we wanted to flag/unflag a legislation proposal.
We weren't using `foundation()` in these cases, so after flagging a
debate or a comment, we had to reload the page before we could unflag
it.
We're also adding a test for the fix in commit ea85059d. This test shows
it's necessary to filter the elements with JavaSctipt using `first()` if
we want the same code to work with comments.
Co-Authored-By: taitus <sebastia.roig@gmail.com>
