We were already saving it as a time, but we didn't offer an interface to
select the time due to lack of decent browser support for this field
back when this feature was added.
However, nowadays all major browsers support this field type and, at the
time of writing, at least 86.5% of the browsers support it [1]. This
percentage could be much higher, since support in 11.25% of the browsers
is unknown.
Note we still need to support the case where this field isn't supported,
and so we offer a fallback and on the server side we don't assume we're
always getting a time. We're doing a strange hack so we set the field
type to text before changing its value; otherwise old Firefox browsers
crashed.
Also note that, until now, we were storing end dates in the database as
a date with 00:00 as its time, but we were considering the poll to be
open until 23:59 that day. So, in order to keep backwards compatibility,
we're adding a task to update the dates of existing polls so we get the
same behavior we had until now.
This also means budget polls are now created so they end at the
beginning of the day when the balloting phase ends. This is consistent
with the dates we display in the budget phases table.
Finally, there's one test where we're using `beginning_of_minute` when
creating a poll. That's because Chrome provides an interface to enter a
time in a `%H:%M` format when the "seconds" value of the provided time
is zero. However, when the "seconds" value isn't zero, Chrome provides
an interface to enter a time in a `%H:%M:%S` format. Since Capybara
doesn't enter the seconds when using `fill_in` with a time, the test
failed when Capybara tried to enter a time in the `%H:%M` format when
Chrome expected a time in the `%H:%M:%S` format.
To solve this last point, an alternative would be to manually provide
the format when using `fill_in` so it includes the seconds.
[1] https://caniuse.com/mdn-html_elements_input_type_datetime-local
This was the only place where we used the `? <= field` format; we use
the `field >= ?` format everywhere else.
We're also adding a variable to make it easier to understand that the
value is the same in both cases and to make the line shorter ;).
The reason why we were displaying the ending date as "one second before
the actual ending" was that, when seeing that a phase ends at a date
like "2000-12-31 00:00", we might end up thinking that the phase will
finished at the midnight between December 31st and January the 1st,
while it actually ends at the midnight between December the 30th and
December the 31st.
This is particularly important because we use a date field to select the
date of a phase and if select December the 31st, it will be stored in
the database as "2000-12-31 00:00". So, instead, in this case we display
"2000-12-30 23:59", which is less confusing.
But now we're going to add support for setting a time on polls, which
means a certain poll might end at 15:30. In this case, displaying that
it ends at 15:29 doesn't make much sense.
We were displaying dates in two different formats in the same component,
leading to strange hacks like manually calling the `call` method or not
being able to use `render_inline` in the tests.
Since we're going to reuse one of these formats outside the budgets
section, we're splitting the component. We're also removing the
mentioned hacks.
This is consistent with the way we show the duration of a budget and its
phases. Since budgets are the section with the most recent changes in
the admin area, we're using it as a reference.
Note that, unlike budgets (which are shown to finish at the beginning of
their ending day), a poll has always been considered to finish at the
end of their ending day, so we're showing it this way.
We're also solving a minor usability issue. While it's pretty intuitive
that a poll starting on a certain date will start at the beginning of
the day, a poll ending on a certain date isn't clear about when it
finishes exactly: is it at the beginning of the day, or at the end of
the day?
So now we're making this point clear.
In some cases (e.g. after editing or creating a resource
with errors) the default back_link did not redirect to the
expected page.
Now we force the back_links to the index pages, so we
always get the desired redirect.
These routes aren't used since commits (2993ef8707, 88a7a29d27)
In parallel while these routes were being removed, the route file
was being split into different files, and they were included again
in the commit 1cd47da9d4.
Until now, in order to edit an answer, we had to click on its title on
the table and then on the "Edit answer" link.
That was tedious and different from what we usually do in the admin
section. Furthermore, the code for the answers table was written twice
and when we modified it we forgot to update the one in the `show`
action, meaning the table here provided less information than the
information present in the answers tables.
Co-Authored-By: Javi Martín <javim@elretirao.net>
We might change the style of this caption or remove it completely in the
future. In the meantime, we use the right HTML tag for the task to give
information regarding what the table is about, and that tag is
`<caption>`.
After removing a question from a poll it makes more sense to redirect to
your own poll show page in order to manage their questions.
Currently it is redirecting to the questions index page where all the
questions from all the polls are displayed and takes you completely out
of the context of the poll you are in.
In the future we will remove this index question page.
Actions :search_booths and :search_officers in admin polls controller
are moved to other controllers since commit 20e31133a for
:search_booths and commit 19ec7f93b for :search_officers.
This then allows us to remove the code that references these actions in
the controller and in the administrator abilities.
