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.
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.
In some sections we had negative top margins to compensate the header
bottom margin. However, when adding a banner between the header and
those sections, the negative margin caused the content of those sections
to overlap with the content of the banner.
Removing the negative margins when a banner is present solves the issue.
When a user recovers a page from browser history where placed a
marker in different map pane (visible map layer) marker was
successfully added to the map but the map center is the one
defined at Settings map properties so the marker was not visible
to the user.
Now when map_location form has valid coordinates we use them
instead of default map center settings. This will avoid the user to
have to rellocate the marker (or find the correct pane where the
marker was added) if already placed.
When using an editable map is better to load marker latitude, longitude and
map zoom from form fields so we can show the marker at latest position defined
by user when the page was restored from browser history.
To reproduce this behavior:
0. Undo this commit
1. Go to new proposal page
2. Place the proposal map marker
3. Go away to any other page
4. Restore new proposal page from browser history.
At this point you should not see the recently placed marker.
The same thing happens when editing a proposal.
If we do not do this a map could be initialized twice times or more
when restoring a page with a map causing weird UI effects and
loading some map layers also twice times or more.
Need to add a maps array to be able to store all initialized
(visible) maps so we can destroy them when needed. Notice that
we are destroying maps also when admin settings tabs changes
(only visible ones), this is again to avoid to re-initialize map more
than once when users navigate through settings tabs, another
option to the settings issue could be to detect if the map was
already initialized to skip uneeded initialization.
It was being duplicated when restoring a page by using browser
history. With this solution we will avoid to have screen readers
descriptions more than once inside any sociual share button.
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.
If we do not destroy annotator app before storing the page at
browser cache we will unnecesarily initialize annotations twice (or
more) duplicating Annotator HTML markup and causing
unexpected errors.
Without this commit you will find an error when restoring a page with
annotator, you can click on any annotation and you will see the annotation
comments are being loaded twice.
IMO this is an idempotency issue within Annotator JS library.
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.
Sometimes we define URLs for POST requests which are not defined for GET
requests, such as "/residence", so redirecting to it after signing out
results in a routing error.
So instead of using the request referer, we're using the stored location
devise uses, and we're not storing locations in POST requests.
For reasons I'm not sure about, the homepage (and the welcome pages)
were an exception in our "redirect users to the same page they were"
policy.
I'm not sure about the welcome pages (no test was present indicating
they should behave in a special way), but in the case of the home page,
it was a bit annoying to be redirected to a different place after
signing in.
When signing in from a page containing GET params, like
`/budgets/1/investments?heading_id=4`, we were redirected to a URL
without those GET params; in this case, `/budgets/1/investments`.
Using the request fullpath, as recommended in the devise documentation,
keeps these parameters when redirecting.
