This way it's easier to refactor it.
Note we're using `with_request_url` in the tests because the component
renders the locale switcher, which needs a URL in order to work. This
doesn't affect whether we're in the management section or not.
Note we could use `acts_as_paranoid` with the `without_default_scope`
option, but we aren't doing so because it isn't possible to consider
deleted records in uniqueness validations with the paranoia gem [1].
I've added tests for these cases so we don't accidentally add
`acts_as_paranoid` in the future.
Also note we're extracting a `RowComponent` because, when
enabling/disabling a tenant, we're also enabling/disabling the link
pointing to its URL, and so we need to update the URL column after the
AJAX call.
[1] See issues 285 and 319 in https://github.com/rubysherpas/paranoia/
This is consistent with the way we use separate actions to hide and
restore records, which is similar to enabling and disabling a record. We
might do something similar with the `toggle_selection` actions in the
future. For now, we're only doing it with budget phases because we're
going to add a similar switch control to hide and restore tenants.
We're also making these actions idempotent, so sending many requests to
the same action will get the same result, which wasn't the case with the
`toggle` action. Although it's a low probability case, the `toggle`
action could result in disabling a phase when trying to enable it if
someone else has enabled it between the time the page loaded and the
time the admin clicked on the "enable" button.
We were using similar code in four different places; six, if we count
the welcome pages seeds. Reducing duplication in the pages seeds is a
bit tricky because administrators are supposed to edit their content and
might remove the HTML class we use to define styles. However, we can
share the code everywhere else.
Note that there's a bug in the application since we show that level 2
users cannot vote for budget projects but we give them permission to do
so in the abilities model. We're keeping the same behavior after this
refactoring but we might change it in the future.
When voting investment projects, the sidebar was rendered without the
`@heading_content_blocks` being set. That resulted in a 500 error when
the heading had content blocks.
By extracting the logic to a component, we make sure the heading content
blocks are properly set every time this code is rendered, no matter
which controller is rendering the view.
We were using the same logic in many different places, so we're
simplifying the code. I'm not convinced about the method names, though,
so we might change them in the future.
Note using this method for the default tenant in the `TenantDiskService`
class resulted in a `//` in the path, which is probably harmless but
very ugly and it also generates a different key than the one we got
until now. I've added an extra test to make sure that isn't the case.
We forgot to do so in commit d827768c0. In order to avoid the same
mistake in the future, we're extracting a method to get these
attributes. We're also adding tests, since we didn't have any tests to
check that the `dir` attribute was properly set.
Note we aren't allowing to delete a tenant because it would delete all
its data, so this action is a very dangerous one. We might need to add a
warning when creating a tenant, indicating the tenant cannot be
destroyed. We can also add an action to delete a tenant which forces the
admin to write the name of the tenant before deleting it and with a big
warning about the danger of this operation.
For now, we're letting administrators of the "main" (default) tenant to
create other tenants. However, we're only allowing to manage tenants
when the multitenancy configuration option is enabled. This way the
interface won't get in the way on single-tenant applications.
We've thought about creating a new role to manage tenants or a new URL
out of the admin area. We aren't doing so for simplicity purposes and
because we want to keep CONSUL working the same way it has for
single-tenant installations, but we might change it in the future.
There's also the fact that by default we create one user with a known
password, and if by default we create a new role and a new user to
handle tenants, the chances of people forgetting to change the password
of one of these users increases dramatically, particularly if they
aren't using multitenancy.
While we ping some search engines (currently, only Google) when
generating the sitemap files, we weren't telling search engines
accessing through the `robots.txt` file where to find the sitemap. Now
we're doing so, using the right sitemap file for the right tenant.
The `reload` method added to max_votes validation is needed because the
author gets here with some changes because of the around_action
`switch_locale`, which adds some changes to the current user record and
therefore, the lock method raises an exception when trying to lock it
requiring us to save or discard those record changes.
We've been using the `url` Setting for a long time, but since then we've
added a few references to `root_url` to this file, so we're now adding
consistency. We're also removing a now unnecessary condition.
We were using `Setting["url"]` to verify the content belonged to the
application URL, but we can use `root_url` instead.
Note that means we need to include the port when filling in forms in the
tests, since in tests URL helpers like `polymorphic_url` don't include
the port, but a port is automatically added when actually making the
request.
This task was "temporarily" removed in commit 7b6619528. Since that was
done three and a half years ago, right after the dashboard was
introduced, I think it's time to make this "temporary" measure a bit
more permanent ;).
By using the Rails `button_to` helper (which generates a form), and adapting the
response to `html` and `js` formats, the feature works with or without javascript
enabled.
Note that the `create` action doesn't create an image but updates an
answer instead. We're removing the references to `:create` in the
abilities since it isn't used.
In the future we might change the form to add an image to an answer
because it's been broken for ages since it shows all the attached
images.
Adding, modifiying, and/or deleting questions for an already started
poll is far away from being democratic and can lead to unwanted side
effects like missing votes in the results or stats.
So, from now on, only modifiying questions will be possible only if
the poll has not started yet.
In this form, the only case where `poll` might be present without
`question.poll` being present to is going to be the `new` action. We can
assign the poll in the `new` action and get rid of the `poll` variable
in the form.
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 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.
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>`.
We were getting some deprecation warnings:
DEPRECATION WARNING: `Module#parent` has been renamed to
`module_parent`. `parent` is deprecated and will be removed in Rails
6.1.
DEPRECATION WARNING: `Module#parents` has been renamed to
`module_parents`. `parents` is deprecated and will be removed in Rails
6.1.
