Calculating winners before the balloting is over is useless (results
aren't published at that point) and can lead to the wrong results since
users are still voting and results might change.
And we were showing the button to calculate winners even when a budget
had finished. However, in this case the action to calculate winners did
nothing, which resulted in administrators seeing nothing happened after
pressing the button.
Before, users needed to navigate to the list of groups in order to
add, edit or delete a group.
Also, they need to navigate to the list of groups first, and then to
the list of headings for that group in order to add, edit or delete a
heading.
Now, it's possible to do all these actions for any group or heading
from the participatory budget view to bring simplicity and to reduce
the number of clicks from a user perspective.
Co-Authored-By: Javi Martín <javim@elretirao.net>
IMHO selecting in how many headings it's possible to support investments
isn't necessary when there's only one option to choose from. It's
obvious that if there's only one heading, it will be impossible to
select investments from more than one heading.
In the past it would have been confusing to add a way to directly
enable/disable a phase in the phases table because it was in the middle
of the form. So we would have had next to each other controls that don't
do anything until the form is sent and controls which modify the
database immediately. That's why we couldn't add the checkboxes we used
when using the wizard.
Now the phases aren't on the same page as the budget form, so we can
edit them independently. We're using a switch, so it's consistent with
the way we enable/disable features. We could have used checkboxes, but
with checkboxes, users expect they aren't changing anything until they
click on a button to send the form, so we'd have to add a button, and it
might be missed since we're going to add "buttons" for headings and
groups to this page which won't send a form but will be links.
Since we're changing the element with JavaScript after an AJAX call, we
need a way to find the button we're changing. The easiest way is adding
an ID attribute to all admin actions buttons/links.
Having links in the middle of a form distracts users from the task of
filling in the form, and following a link before submitting the form
will mean whatever has been filled in is lost.
And the budgets form is already very long and hard to fill in. Having
the phases table in the middle of it made it even harder. And, since
we're planning to add the option to manage groups and headings from the
same page, it's better to have a dedicated page for the form.
Usability tests showed some users were struggling when seeing the word
"Required" as a legend (it's actually styled as a title), since this
isn't a common pattern when filling in forms. They were expecting
something like "Fields with * are required", and so the "Required" text
alone made them feel the sentence wasn't complete.
We could also add an "*" to required fields in addition to the
"Required" text. In this case, however, some users wondered what the
asterisk was about: "It can't mean 'required' because they've already
said these fields are required".
We'll probably have to revisit required and optional fields again. For
now, we're just doing a small improvement.
Since we aren't very consistent in the styles for submit buttons in the
admin section, it was possible to accidentally press the "Calculate
Winner Investments" link after filling in the form. This wouldn't submit
the form and so the changes wouldn't be saved.
It's also a bit confusing for users. After filling in a form, users
expect a submit button. When finding two buttons, they've got to stop to
think which one is the one they've got to press.
Furthermore, the "Calculate Winner Investments" link would work better
as a button instead of a link, for the reasons mentioned in commit
5311daadf. Since HTML forms can't be nested, that would mean treating
this button in a different way than the rest of the buttons in the
application.
Moving the link before the form solves the issue.
Since now we've got the budget actions before the budget form, we're
grouping these actions together with the "Preview" action. We're not
adding the "Publish budget" button as well to this group because it's
got an associated message.
Even if it was looking OK using `margin-left`, there were probably edge
cases where it wouldn't behave as we expected.
As mentioned in the previous commit, this won't be necessary once
everyone uses browsers supporting the `gap` property in flexbox layouts,
but this won't happen for a few years.
In a few months we might also consider using the `margin-inline-start`
property, which is currently supported by about 97% of the browsers [1].
[1] https://caniuse.com/css-logical-props
This way we remove duplication and it'll be easier to add better support
for RTL languages.
In a few years this might not be necessary since support for the `gap`
property in a flexbox layout will improve. At the time of writing,
however, only 86.5% of the browsers support it [1].
[1] https://caniuse.com/flexbox-gap
These tests don't work without JavaScript. They were passing because the
`within` method always passes in component tests.
This reverts most of commit 822140a14.
In component tests, the `within` method is actually an alias to RSpec's
`be_within` matcher, which is used to test numeric ranges. That meant
the tests always passed, even when there were bugs on the page.
In order to use `within` in component tests, we have to use
`page.within`. However, that also fails, since there's no such method
for `Capybara::Node::Simple'` objects, which are used in component
tests.
So we're using `page.find` instead.
See also pull request 945 in https://github.com/github/view_component
We were executing SQL queries searching for translations even for
records which were not persisted in the database and therefore had no
translations.
So we're now only looking for translations when the record is persisted.
Note that, when the record isn't persisted, we're using `I18n.translate`
instead of the `t` method. That's because the `t` method would also
perform database queries since we overwrite the `t` method in the
`i18n_translation` initializer.
On tabs with many records, like the proposals tab, requests are now up
to three times faster on production environments.
Tests related to this part of the application were failing sometimes
because requests took longer than `Capybara.default_max_wait_time`.
After these changes, the custom information texts pages load about 30%
faster when running the tests.
This way it's easier to test; changing it will also be easier.
During my experiments I made a mistake which wasn't covered by the test
suite. We're adding a test for this case.
Note we're using `i18n_content` in the component instead of `content`
because there's already a `content` method provided by ViewComponent.
When we try to register with omniauth and the email or username already exists,
we use the finish_signup and do_finish_signup actions to allow the user to choose
another email or username.
The do_finish_signup action of the registration controller calls the
send_oauth_confirmation_instructions method which is responsible for sending the
confirmation email.
In this method we were only validating the case that the email is duplicated. Now
we add one more condition that allows us to send the instructions for the case in
which we have had to change our username.
The integration between Airbrake/Errbit and DelayedJob wasn't working
because we require our dependencies in alphabetic order, and so by the
time `airbrake` was required, `delayed_job` wasn't loaded.
So we're manually requiring the integration.
We weren't showing the details of answers without a description, even if
they had images, videos or documents. Some users found that behavior
unexpected since the description isn't a mandatory field and so they
left it blank, but they added images to that answer and they didn't
appear on the poll page.
Note we had a condition not to show the title of an answer when it had
no description. I think that condition was redundant because answers
without a description weren't loaded in the first place. Anyway, that
condition doesn't make sense anymore because we're displaying answers
with images but no description.
Adding the error to the translation means Rails will automatically show
the error message in the view.
We're also adding a test to make sure the error message is correctly
displayed.
We now have duplication in the validation rules, however. Validating
translatable attributes is still a bit of mess.
As mentioned in commit b7f6c4c43:
> [In Internet Explorer] the `flex: 1` property doesn't work so well
> when `flex-direction` is set to `column`. We're replacing it with
> `flex-grow: 1`. No need to set other `flex-basis` nor `flex-shrink`
> since in this case the default values will work just fine.
This column wasn't used in any released Consul version since it was only
used during development. For the same reason, the task to migrate the
information in the `link` column to the `links` table isn't needed
either.
