We were testing what happens when clicking on a geozone without HTML
coordinates, which won't happen in a real browser.
So we're now defining the HTML coordinates and clicking on the area in
the test, which is what real people will do.
We also avoid having two consecutive `visit` calls, which will interfere
with the way we plan to test the presence of the <main> tag after every
`visit`.
Note that, the test didn't work with the HTML coordinates defined in the
`with_html_coordinates` trait, with Capybara showing the following
error:
```
Selenium::WebDriver::Error::ElementClickInterceptedError:
element click intercepted: Element
<area shape="poly"
coords="30,139,45,153,77,148,107,165"
href="/proposals?search=California"
title="California" alt="California">
is not clickable at point (413, 456).
Other element would receive the click:
<img usemap="#map" src="/assets/map.jpg">
```
The cause of this error was the strange shape of the polygon, which was
greatly concave and and so the middle of its area wasn't part of it.
We're changing the polygon so it's now convex and when Capybara clicks
on its middle point everything will work as expected.
When we create a budget heading through factories it's placed at Puerta del Sol,
Madrid. It seems reasonable that the `map_location` factory places the points near
there.
Before these changes sometimes the map center was placed in Madrid while map
locations were placed in Greenwich, therefore markers were not visible in the
map current pane.
Note we're excluding a few files:
* Configuration files that weren't generated by us
* Migration files that weren't generated by us
* The Gemfile, since it includes an important comment that must be on
the same line as the gem declaration
* The Budget::Stats class, since the heading statistics are a mess and
having shorter lines would require a lot of refactoring
* Add Tables option to Redcarpet in Legislation draft
* Allow table tags in Admin Legislation Sanitizer
* Add Test to render markdown tables in Legislation drafts
* Add Test for Admin Legislation Sanitizer
We include test for image, table and h1 to h6 tags and additional tests to strengthen the allowed and disallowed parameters
* Add Table from markdown test in System and Factories
* Add test to render tables for admin user
* Remove comment line about Redcarpet options
* Edit custom css for legislation draft table to make it responsive
Note that in the budgets wizard test we now create district with no
associated geozone, so the text "all city" will appear in the districts
table too, meaning we can't use `within "section", text: "All city" do`
anymore since it would result in an ambiguous match.
Co-Authored-By: Julian Herrero <microweb10@gmail.com>
Co-Authored-By: Javi Martín <javim@elretirao.net>
It was possible to remove a map location from a different proposal (even
one created by a different author) by modifying the hidden `id`
parameter in the form.
So we're making sure the map location we destroy is the one associated
to the proposal we're updating.
Since we're now using the `@proposal` instance variable in the
`destroy_map_location_association` method, we're calling that method
after loading the resource with cancancan.
We were rendering the whole sidebar again, which wasn't necessary since
most of it remains unchanged. This resulted in complicated code to pass
the necessary information to render the same map that was already
rendered. Furthermore, when users had been moving the map around or
zooming out, we were resetting the map to its default settings after
voting, which was potentially annoying.
This also fixes the wrong investments being displayed in the map after
voting; only the investments on the current page were displayed in this
case while the index displayed all of them.
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.
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.
We were using this hack in order to allow `File.new` attachments in
tests files. However, we can use the `fixture_file_upload` helper
instead.
Just like it happened with `file_fixture`, this helper method doesn't
work in fixtures, so in this case we're using `Rack::Test::UploadedFile`
instead.
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
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.
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.
We were already doing so for debates and investments.
We probably never noticed because this is an edge case that requires
enabling a feature, people adding comments, and then disabling the
feature.
We're already using a custom controller to handle direct uploads.
Besides, as mentioned by one of Active Storage co-authors [1], the
Active Storage DirectUploadsController doesn't provide any
authentication or validation at all, meaning anyone could create blobs
in our database by posting to `/rails/active_storage/direct_uploads`.
The response there could be then used to upload any file (again, without
validation) to `/rails/active_storage/disk/`.
For now, we're monkey-patching the controllers in order to send
unauthorized responses, since we aren't using these routes. If we ever
enable direct uploads with Active Storage, we'll have to add some sort
of authentication.
Similar upload solutions like CKEditor don't have this issue since their
controllers inherit from `ApplicationController` (which includes
authorization rules), while Active Storage controllers inherit from
`ActionController::Base`.
[1] https://discuss.rubyonrails.org/t/activestorage-direct-uploads-safe-by-default-how-to-make-it-safe/74863/2
Since version 2.0 introduced many breaking changes, we're upgrading to
it first.
The changes have been done by installing the rubocop-faker gem and
running:
```
rubocop \
--require rubocop-faker \
--only Faker/DeprecatedArguments \
--auto-correct
```
Instead of adding the padding to each individual element inside the
container, why not adding padding to the container itself? The answer is
"because we want the background of the children elements to take the
width of the whole screen". But this generates either HTML cluttered
with elements to add padding or repetitive padding definitions in the
CSS.
So now we only define the padding once, and when an element requires a
full width background or border, we use the `full-width-background`
mixin.
In this case the code is a bit more complex because the header is also
used in the dashboard and admin layouts:
* In the public layout, the body has a margin, so we include the mixin
to take margin into account
* In the dashboard layout, the header itself has a margin, so we include
the same mixin
* In the admin layout, the headet doesn't have a margin but gets the
whole width, so in this case we include the mixin which dosen't take
the margin into account
In the future, the idea is to apply this principle to the <body>
element and remove the `@include grid-column-gutter` in the CSS as well
as the `small-12 column` classes in the HTML.
Note we use the `calc()` function inside the mixin instead of using it
in the `$full-width-margin` variable. That way we avoid nested `calc()`
operations, which don't work in Internet Explorer.
Also note we're using `flex-grow: 1` to make one element appear on the
left of the screen and the other one on the right. It would be easier to
use `justify-content: space-between` (which is actually the default for
the top-bar element). However, there's a bug in Internet Explorer and
old versions of Firefox; they include the absolutely-positioned
`::before` element we use to set the full width background when
calculating where to position the elements. The bug was fixed in Firefox
52 (released in 2017).
Finally, we're removing the padding from our logo. In order to allow
logos like the new one and at the same time provide backwards
compatibility to logos in existing CONSUL installations, we're relaxing
the validation rule for the logo width.
Previously the draft mode was a phase of the PB, but that had some
limitations.
Now the phase drafting disappears and therefore the PB can have the
status published or not published (in draft mode).
That will give more flexibility in order to navigate through the
different phases and see how it looks for administrators before
publishing the PB and everybody can see.
By default, the PB is always created in draft mode, so it gives you
the flexibility to adjust and modify anything before publishing it.
This is similar to what we do with investments, which belong to a heading
but also belong to a budget. In our case, the reason is we've been asked
to add local targets which belong to a goal but are not related to any
existing target.
Even though we're not implementing that case right now, we're adding the
relation so we don't have to add data migrations in the future.
and its relation with relatables
Note about sdg_review factory: Cannot use the constantize method on
the relatable_type as long as the relatable classes will be loaded and
this will throw an exception because the database is not available at
factiry definition time.
and its relation with the SDG goal model.
Add comparable module be able to sort collections of targets
by code attribute.
Co-Authored-By: Javi Martín <35156+javierm@users.noreply.github.com>
