We were using partials to render components in order to ease the
transition of custom code from earlier versions of Consul. However,
that was back in Consul 1.4, and now these views looked a bit messy
since they sometimes rendered components and sometimes they
rendered partials.
We weren't using the `admin-top-bar` class since commit e6c1cf774, and
we can always use the `.admin .top-bar` selector if we need to. And the
`row expanded` classes basically give an element a width of 100%, which
is already the default width for block elements.
We were using the same code for the button in both the public and admin
headers, so we're removing the duplication.
Since the menu and the button must go together, and the contents of the
menu are different for different layouts, we're passing these contents
using a block.
Note the ID of the menu was `responsive-menu` in the public section but
`responsive_menu` in the admin section. Since we usually use underscores
for IDs and dashes for classes, we're keeping the one with the
underscore.
So now it uses the same interface and styles as the main layout. On
small screens, it's easier to play with the menu when the button is on
the left because the menu it opens is aligned to the left.
Note that now we can get rid of the title-bar class; we didn't use the
styles in the public area since commit dcec003d0, and we were overriding
all the Foundation styles in the admin area with the exception of the
padding, which we no longer need.
This way we follow the convention of one stylesheet per component.
Note that we depend on Foundation's `menu` class for some of the
styles and JavaScript behavior, so we're keeping both the `menu` and
`account-menu` classes.
We were passing a hash of options instead of converting them to keyword
parameters, which resulted in warnings on Ruby 2.7:
```
app/components/admin/table_actions_component.html.erb:5: warning: Using
the last argument as keyword parameters is deprecated; maybe ** should
be added to the call
app/components/admin/table_actions_component.html.erb:9: warning: Using
the last argument as keyword parameters is deprecated; maybe ** should
be added to the call
app/components/admin/widget/cards/row_component.html.erb:20: warning:
Using the last argument as keyword parameters is deprecated; maybe **
should be added to the call
app/components/admin/widget/cards/table_component.html.erb:14: warning:
Using the last argument as keyword parameters is deprecated; maybe **
should be added to the call
```
We were using an optional parameter followed by keyword parameters,
which caused a warning with Ruby 2.7:
```
app/components/shared/link_list_component.rb:20: warning: Using the last
argument as keyword parameters is deprecated; maybe ** should be added
to the call
```
I've tried to make `current:` a named parameter as well and then change
all method calls to `link_list`, but was still getting the same warning.
Might have something to do with the fact that we're dealing with arrays
with hashes inside them instead of passing the keyword arguments
directly to the method.
We weren't showing the year when a page was created/updated, and we
were displaying the created date instead of the updated one.
Co-Authored-By: Diego Calvo <diego.calvo@enreda.coop>
We're trying to be consistent; in the past, we had the partials
"shared/admin_login_items", "layouts/notification_item" and
"devise/menu/login_items". Now we're moving all these partials to
components in the `Layout` namespace.
This way it'll be easier to decide when they should be rendered.
In order to be consistent, we're using the `Layout` module for both
components; previously, the navigation partial was in the `shared`
folder while the footer partial was in the `layout` folder, which IMHO
didn't make much sense.
This way we remove the duplication in the layouts which had these links.
Since we're now passing the `current_user` option to partials in all
cases, IMHO the code is easier to follow if we use the
`Layout::NotificationItemComponent` instead of its partial.
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.
As mentioned in commit 925f04e3f, icon classes make screen readers
announce strange symbols and aren't properly displayed for people who
have changed their preferred font family.
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.
In general, we don't use links inside admin tables because we don't know
where the link will point to, and use "view" actions/links instead.
However, in this case, we're showing a URL, so it's perfectly obvious
where the link will point to. And so it makes sense to use the URL as a
link instead of using a "view" action/link.
Some institutions using CONSUL have expressed interest in this feature
since some of their tenants might already have their own domains.
We've considered many options for the user interface to select whether
we're using a subdomain or a domain, like having two separate fields,
using a check box, ... In the end we've chosen radio buttons because
they make it easier to follow a logical sequence: first you decide
whether you're introducing a domain or subdomain, and then you enter it.
We've also considered hiding this option and assuming "if it's got a
dot, it's a domain". However, this wouldn't work with nested subdomains
and it wouldn't work with domains which are simply machine names.
Note that a group of radio buttons (or check boxes) is difficult to
style when the text of the label might expand over more than one line
(as is the case here on small screens); in this case, most solutions
result in the second line of the label appearing immediately under the
radio button, instead of being aligned with the first line of the label.
That's why I've added a container for the input+label combination.
We were displaying an icon showing that certain actions can't be
performed. However, people who can't see the icons were hearing that
they _can_ perform certain actions while the opposite is true.
We've considered other options to solve this problem. One was to split
the list in two: actions that can be performed and actions that can't be
performed. It was tricky because in some cases we're listing that
actions that can be performed now and in other cases we're displaying
the actions that people will be able to perform once they verify their
account.
Another option was to include the word "Cannot" as a prefix instead of
"Additional verification needed". We haven't done so because, while in
English we say "cannot do this thing", in other languages they say
"this thing cannot do".
So we've gone with a solution where people hearing what's on the screen
know what's going on and we don't have to make big changes in the code.
As mentioned in commit 925f04e3f, icon classes make screen readers
announce strange symbols and aren't properly displayed for people who
have changed their preferred font family.
This way we simplify the ERB code.
Due to the bug mentioned in the previous commit, we're keeping the
original code instead of using `can?` to check permissions.
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.
This way it will be possible to write CSS and JavaScript code that will
only apply to specific tenants.
Note that CSS customization is still limited because it isn't possible
to use different SCSS variables per tenant.
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.
