We modified the link that previously redirected us to the "My content"
page to redirect us to the new page for managing subscriptions.
We also adapted the existing generic text by adding a description of
the related notification.
You can update the same "notifications" section that we allow you to
update in "my account".
This "subscriptions" section differs from the "my account" section
because we do not need to be logged in to update the status of the
notifications.
The user can access this page without being logged in.
We identify the user through the "subscriptions_token" parameter and
show a list of the notifications that can be enable/disable.
We will return a 404 error in case someone accesses the page with a
non-existent token.
We also control the case that some anonymous user tries to access the
page without any token, by returning the CanCan::AccessDenied exception.
In commit 905ac48bb we mentioned:
> Since we don't use `asset_path` to reference assets in the public
> folder, we can safely disable the `unknown_asset_fallback` option.
However, `asset_path` is used by the wicked_pdf gem when calling the
`wicked_pdf_stylesheet_link_tag` method. This method also checks the CSS
files, searching for `url()` calls and converting any relative URLs
referenced there to absolute URLs.
However, when compiling assets on production, our `application.css` file
contains the following line imported from Leaflet which says:
```
behavior: url(#default#VML);
```
When passing this URL to `asset_path` (which is something the wicked_pdf
gem does automatically), it doesn't find the URL, and so this call
crashes unless we enable then `unknown_asset_fallback` option.
Since the dashboard poster is a feature we might remove in the future,
we're avoiding changing a Rails global configuration just for this
feature. So, instead of enabling the `unknown_asset_fallback` option,
we're changing the `poster.pdf` view so it doesn't load all the CSS of
the application but only the CSS it needs.
Note we aren't adding a test case because this bug is only present on
production environments when assets have been precompiled.
In the past, users had permission to edit their own legislation
proposals. However, that changed in commit ebfa3fb01, where we replaced
the `can` method with `cannot`.
An easier way to remove this permission is to simply remove the whole
statement, since by default users don't have permissions to do anything.
We're also adding a test checking users can't edit their own legislation
proposals, since it was missing.
The `edit` action is automatically authorized with the rules used for
`:update`, the same way the `new` action is authorized with the rules
used for `:create`.
So we don't need to authorize the edit and new actions.
These changes make it easier for institutions customizing Consul to
notice what they need to change if (for instance) they want users to be
able to edit investments under certain conditions.
See foundation/foundation-sites issue 12167, which was fixed in
Foundation 6.7.1. However, since Foundation 6.7 requires Node 12 and the
foundation-rails gem hasn't been maintained for a year and a half, we're
not updating for now.
We forgot to remove it in commit f28a5cc49.
The generated HTML was invalid, with the error:
> Element meta is missing one or more of the following attributes:
> content, property.
It was a bit confusing to press the "hide" button and then see the user
listed as "blocked". Some moderators might think they accidentally
pressed the wrong button.
In the moderation section there's no clear indicator as to what the
"Hide" and "Block" buttons do and the difference between them.
Since we're using confirmation dialogs in all moderation actions except
these ones, we're adding them here as well, so the difference will
appear in the dialog.
This isn't a very good solution, though, since the confirmation dialog
comes after clicking the button and users have already been wondering
whether clicking that button will be the right choice. A better solution
would be making the purpose clear before the button is clicked, although
that's something we don't do anywhere in the admin/moderation sections.
The test "Action links remember the pagination setting and the filter"
was failing sometimes because it assumed the third user created was
going to appear in the third place, but that wasn't always the case.
So we're using the same order we use in the rest of the sections dealing
with hidden content.
In the past, whenever we hid users, we also hid their comments.
However, we've now implemented an action to hide users without hiding
their comments. In this case, we still want to show the comment, but we
weren't doing so.
This is useful for people using screen readers, since the character used
as a separator won't be read aloud.
Since many screen readers also read content generated via CSS
pseudoelements, we aren't using `content: "|";` or similar but using
elements with a very small width instead.
We're continuing to replace links with buttons, for the reasons
explained in commit 5311daadf.
Since we're using the admin action component, we can also simplify the
logic handling the confirmation message.
In order to avoid duplicate IDs when generating buttons to block the
same author more than once in a page, we're including the record dom_id
in the ID of the button to block an author.
This HTML wasn't valid because it was a <span> containing the <div
class="reply"> element and it wasn't needed because there aren't any
flag actions in proposal notifications.
The `hide` action was calling the `block` method while the `soft_block`
action was calling the `hide` method.
Combined with the fact that we also have a `block` permission which is
used in `ModerateActions` the logic was hard to follow.
Note that in proposal notifications we're writing the call to
render the component in the same line as the <div class="reply">
definition in order to be able to use the `:empty` selector when the
component renders nothing. No browser matches whitespace with the
`:empty` selector, so we can't add newline characters inside the tag. A
more elegant solution would be extracting the proposal notification
actions to a component and only rendering it if the moderation actions
component is rendered.
Other than removing a redundant action, we're fixing two bugs when
blocking an author using the links in the public views:
* We were always redirecting to the debates index, even if we blocked
the author of a proposal or an investment
* We weren't showing any kind of success message
Having proper headers makes it more accessible.
We're also using the table actions component because we're going to add
another action. Since table actions use a flex layout, we have to tweak
the styles a little bit. For that, I'm adding a <main> element which
will make it possible to style just this table while also providing an
extra shortcut for people using screen readers.
We're continuing to replace links with buttons, for the reasons
explained in commit 5311daadf.
We're also adding an ARIA label since on the same page there might be
several links to block different users.
This way we don't have to use the `send` method in other places, like
the AdminNotification class, and we can change the internal
implementation at any point.
We're going to add geozones as user segments, so it's handy to have the
method in the UserSegments class.
We're also changing the `user_segment_emails` parameter name for
consistency and simplicity.
We're going to make it dynamic using the geozones. Besides, class
methods can be overwritten using custom models, while constants can't be
overwritten without getting a warning [1].
Makes the definition of segments with geozones a little cleaner. I
think it’s worth it, compared to the slight memory gain of using a
constant [2].
[1] warning: already initialized constant UserSegments::SEGMENTS
[2] https://stackoverflow.com/questions/15903835/class-method-vs-constant-in-ruby-rails#answer-15903970
Programmers can take advantage of this feature when defining custom
default settings. And, since many CONSUL installations had custom
changes in the `custom/verification/residence.rb` model and those
changes might use regular expressions, we're making it easier to migrate
that code to the new system to define valid postal codes.
We aren't documenting this feature in the description in the admin
section because most administrators don't know what regular expressions
are.
Note that, in order to simplify the setting, we already define the `/\A`
and `\Z/` characters. So, if the custom code had something like
`postal_code =~ /^280/`, the setting would have to be "280*" (without
the quotes) or, in order to comply with a length validation,
"280[0-9]{2}" (without the quotes).
Due to the way Madrid handled postal code validations (see issue 533),
by default we were requiring everyone to validate against the local
census *and* to specify valid postal codes.
This could be useful in some cases, but in other cases, the census
validation will be enough and there'll be no need to manually define the
valid postal codes. Besides, some CONSUL installations are used in
organizations or political parties where the postal code validation
doesn't make sense.
In some countries, postal codes are defined with a dash in the middle,
so we're using a colon to define ranges instead. We could also use two
dots, like in Ruby ranges, but IMHO this would cause typos since people
would enter codes separated with three dots or just one dot.
We weren't using the `be_valid` matcher because we had errors in the
census data.
Removing the `before_validation` callback and using a method to get the
census data instead allows us to stub the `census_data` method in the
tests, and so we can use the `be_valid` matcher instead of calling
`valid?` manually and then checking for errors.
Using a field with `type="tel"` causes most mobile phone browsers to
show a numeric keyboard which makes it easy to enter phone numbers.
We aren't using a number field because some browsers show "spinners" to
increment/decrement numbers (which doesn't make much sense in a phone
number) and because they don't allow characters like spaces. Phone
numbers can have characters like spaces, dashes, parenthesis, asterisks,
the plus sign, ...
Since phone number formats vary depending on the region, and sometimes
even within the same region several different formats can be used, for
now we aren't offering any kind of format validation. We could offer a
format validation that rejects just letters (although there are cases
where letters are actually allowed). However, this causes issues at both
the server side and the client side.
We could use a client-side validation adding a `pattern` attribute to
the field, but that would be something unlike anything else we use in
the application, and we would need to to write some JavaScript in order
to use a proper error message.
On the other hand, if we add a server-side validation, we might find out
existing users are invalid, and it would be impossible to update them in
the many places where we update users assuming they were valid in the
first place. We'd have to add a rake task to update existing user
records and make sure they contain a valid phone number or create a
setting so this validation only applies to new CONSUL installations.
Another option would be to add a per-form validation, so the phone
number is only validated in pages where it is introduced.
All the mentioned scenarios offer certain complexities. So, for now,
we're keeping things simple.
Co-Authored-By: decabeza <alberto@decabeza.es>
Now that we also have the "go back to CONSUL" link, the layouts are so
similar that it isn't worth it maintaining both of them separately.
With this change, people using small screens also get the "menu" button
in the management section, just like they do everywhere else.
We're adding the `namespace != "management"` condition so the menu still
shows up in the officing namespace.
Originally there was a link pointing to the FAQ page but it was removed
in commit e14b7b67fb because by default the FAQ page in CONSUL only
contains a placeholder text.
We aren't sure where this link should point:
* FAQ page, only if the FAQ page is published
* Help page, only when the help feature is enabled
* CONSUL technical documentation page
So, for now, we're choosing the easiest solution which is removing the
text completely.
The `commentable_url` method wasn't updated when we added legislation
proposals.
Back when we first created this method, we couldn't pass budget
investments or topics directly to `polymorphic_url` because they are
nested resources. That isn't the case since commit ff93f5a59, so now we
can simplify this method.
We're keeping the `commentable_url` method for now in order to keep
compatibility with custom changes that might use it, although this
method isn't consistent with the `commentable_path` method (which
receives a comment, and not a commentable), and so we might have to
revisit this code in the future.
