So now we'll be able to add them to other sections.
We're also adding a `dependent: :destroy` relation to models having
cards since it doesn't make sense to have cards around when their page
has been destroyed.
We use a different logic to load the card depending on the controller
we're using, and then share the rest of the code. This way we simplify
the code a bit, since we don't have to check for the page_id parameter.
We didn't add any validation rules to the card model. At the very least,
the title should be mandatory.
The fact that the label field is marked as optional in the form but the
other fields are not probably means description and link should be
mandatory as well. However, since there might be institutions using
cards with descriptions but no link or cards with links but no
description, so we're keeping these fields optional for compatibility
reasons. We might change our minds in the future, though.
They were all following the same format.
Note we need to group the `see_all` translation keys together (the same
way it's done with the `most_active` keys) so we don't have an unused
translation warning.
We're also moving the "see all" link in processes outside the feed
content; the same way it's done in debates and proposals and removing
unnecessary classes in the processes feed: the column class is causing
the processes not to be aligned with the debates above them, and the
margin bottom is not needed because the margin of the footer is already
enough.
So tests won't fail when an institution changes the default organization
name.
The tests are also easier to understand now, since it's more obvious
where the "CONSUL" text is coming from.
We were repeating the same code over and over (with a few variants) to
setup tests which require an administrator. We can use a tag and
simplify the code.
In some tables, we had "actions", and some columns were also links
pointing to some places. Having both of them at the same time is
confusing, particularly since traditionally the links in the columns
pointed to the same place as some of the actions (although that's not
the case since commit 48db31cd).
We're still keeping links in tables which don't have an action column.
For instance, the proposals table has a "select" button which would be
harder to use if we had action buttons next to it.
By using real XML responses developers will be able to understand better
how the integration works (the data flow), and the correspondency between
`remote_census` settings and their place at a real XML response.
As `stubbed_responses` methods were removed from the model layer now the
stubbing part should be managed from the test environment code so also
added a new helper module `RemoteCensusSetup` that can be used anywhere
where we need to call the web service.
Co-Authored-By: Javi Martín <javim@elretirao.net>
Now we can use the checkbox label text directly as locator at spec,
also default web_sections are created before every spec by loading
`db/seeds.rb` file so we were duplicating "Proposals" WebSection.
We were allowing users to check/uncheck the "Visible to valuators"
checkbox even when the budget is finished and so the investments cannot
be edited. So users were still able to check/uncheck this attribute, but
the server was silently rejecting these changes.
We've considered removing the column in this case but decided to keep it
since users can already control which columns they'd like to display.
This rule was added in rubocop-rspec 1.39.0. The `visible: false` option
is equivalent to `visible: :all`, but we generally use it meaning
`visible: :hidden` for positive expectations and `visible: :all` for
negative expectations.
The only exceptations are tests where we count the number of map icons
present. I'm assuming in this case we care about the number of map icons
independently on whether they are currently shown in the map, so I'm
keeping the `visible: :all` behavior in this case.
By default, Capybara only finds visible elements, so adding the
`visible: true` option is usually redundant.
We were using it sometimes to make it an obvious contrast with another
test using `visible: false`. However, from the user's perspective, we
don't care whether the element has been removed from the DOM or has been
hidden, so we can just test that the visible selector can't be found.
Besides, using `visible: false` means the test will also pass if the
element is present and visible. However, we want the test to fail if the
element is visible. That's why a couple of JavaScript-dependant tests
were passing even when JavaScript was disabled.
This rule was added in Rubocop 0.89.0. However, there are some false
positives when we don't use interpolation but simply concatenate in
order to avoid long lines. Even if there weren't false positives, there
are places where we concatenate to emphasize the point that we're adding
a certain character to a text.
We might reconsider this rule in the future, since we generally prefer
interpolation over concatenation.
There were places where we had two links pointing to the same place; one
link would be the name/title of a record, and one link would be under
the "actions" column.
This is confusing, since users would probably expect these links to
point to different places (which is what happens in other tables in the
admin section) and might try to click one of them and then the other
one and be surprised when they found out both of them go to the same
page.
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 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).
The JavaScript involved wasn't working since we removed the disable-date
attribute in commit 73ff6881.
We're also improving the JavaScript in two ways:
First, we trigger the `change` event immediately, so when the page loads
date fields are disabled when phases are disabled.
And second, we don't remove the selected dates when disabling a phase,
so disabling it and enabling it again will keep the selected values.
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.
Patch extracted from here the comments on turbolinks issue 253 and
converted to vanilla javascript.
The hide action over datepickers ensures us that opened datepickers
will be closed before leving the page. Previously if you open any
datepicker and then move to previous page you will keep seeing the
datepicker in the restored page.
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>
Its known that initializing a map when it is inside a hidden element
wont work when hidden element is shown, so its makes sense to
avoid initialization of hidden maps.
When a map lives within a hidden layer we need to initialize the
map after the event of showing that hidden layer, in our case when
admin settings tab is shown.
