We were displaying the total number of notifications with a message "You
have N unread notifications", but were using the total number of
notifications instead of the unread ones.
Other than simplifying the view, we can write tests using `click_link`,
which makes the tests more robust. Clicking the `.icon-notification`
element was causing some tests to fail when defining a window height of
750 pixels in the `admin_budgets` branch.
We had one exception running test suite [1]:
```
1) Commenting legislation questions Merged comment threads View
comments of annotations in an included range
Failure/Error: count: annotation.comments.roots.count) %>
ActionView::Template::Error:
PG::ProtocolViolation: ERROR: bind message supplies 0
parameters, but prepared statement "" requires 2
: SELECT COUNT(*) FROM "comments" WHERE "comments"."hidden_at" IS
NULL AND "comments"."commentable_id" = $1 AND
"comments"."commentable_type" = $2 AND "comments"."ancestry" IS NULL
```
Debugging shows this test was run right after the flaggable specs.
There's a chance these exceptions take place because the test is
accessing the database after the browser (chromedriver) process has
already accessed the database.
This is just an attempt at fixing the issue; I don't know whether these
changes will fix it since I've only seen this exception on Github
Actions (never on my machine). Worst case scenario, we're encouraging
good practices of system tests: test things from the user's point of
view.
[1] https://github.com/consul/consul/runs/1856245992
So tests won't fail when an institution changes the default organization
name.
The tests are also easier to understand now, since it's more obvious
where the "CONSUL" text is coming from.
We were repeating the same code over and over (with a few variants) to
setup tests which require an administrator. We can use a tag and
simplify the code.
In some tables, we had "actions", and some columns were also links
pointing to some places. Having both of them at the same time is
confusing, particularly since traditionally the links in the columns
pointed to the same place as some of the actions (although that's not
the case since commit 48db31cd).
We're still keeping links in tables which don't have an action column.
For instance, the proposals table has a "select" button which would be
harder to use if we had action buttons next to it.
This rule was added in rubocop-rspec 1.39.0. The `visible: false` option
is equivalent to `visible: :all`, but we generally use it meaning
`visible: :hidden` for positive expectations and `visible: :all` for
negative expectations.
The only exceptations are tests where we count the number of map icons
present. I'm assuming in this case we care about the number of map icons
independently on whether they are currently shown in the map, so I'm
keeping the `visible: :all` behavior in this case.
By default, Capybara only finds visible elements, so adding the
`visible: true` option is usually redundant.
We were using it sometimes to make it an obvious contrast with another
test using `visible: false`. However, from the user's perspective, we
don't care whether the element has been removed from the DOM or has been
hidden, so we can just test that the visible selector can't be found.
Besides, using `visible: false` means the test will also pass if the
element is present and visible. However, we want the test to fail if the
element is visible. That's why a couple of JavaScript-dependant tests
were passing even when JavaScript was disabled.
This rule was added in Rubocop 0.91.0. A similar rule named
LeakyConstantDeclaration was added in rubocop-rspec 1.34.0.
Note using the FILENAMES constant did not result in an offense using the
ConstantDefinitionInBlock rule but did result in an offense using the
LeakyConstantDeclaration rule. I've simplified the code to get rid of
the constant; not sure why we were adding a constant with `||=` in the
middle of a spec.
When a user recovers a page from browser history where placed a
marker in different map pane (visible map layer) marker was
successfully added to the map but the map center is the one
defined at Settings map properties so the marker was not visible
to the user.
Now when map_location form has valid coordinates we use them
instead of default map center settings. This will avoid the user to
have to rellocate the marker (or find the correct pane where the
marker was added) if already placed.
When using an editable map is better to load marker latitude, longitude and
map zoom from form fields so we can show the marker at latest position defined
by user when the page was restored from browser history.
To reproduce this behavior:
0. Undo this commit
1. Go to new proposal page
2. Place the proposal map marker
3. Go away to any other page
4. Restore new proposal page from browser history.
At this point you should not see the recently placed marker.
The same thing happens when editing a proposal.
If we do not do this a map could be initialized twice times or more
when restoring a page with a map causing weird UI effects and
loading some map layers also twice times or more.
Need to add a maps array to be able to store all initialized
(visible) maps so we can destroy them when needed. Notice that
we are destroying maps also when admin settings tabs changes
(only visible ones), this is again to avoid to re-initialize map more
than once when users navigate through settings tabs, another
option to the settings issue could be to detect if the map was
already initialized to skip uneeded initialization.
We were submitting the form without checking the AJAX request to attach
the image had finished, so sometimes two requests were executed at the
same time. Sometimes this made InvisibleCaptcha to go crazy and report
the form was submitted too quickly.
Checking the first AJAX request has finished before submitting the form
solves the problem.
We were checking `expect_document_has_title(0, "My Title")`, which was
already true before the AJAX request generated by `attach_file` had
finished.
That meant the AJAX request sometimes was handled after this test had
finished, affecting the following test and causing it to fail because
its cookie was overwritten and so `current_user` was set to `nil`.
In the test checking the filename is present, a similar scenario was
taking place: we were updating the `.file-name` element in the `change`
event of `fileupload` (using `App.Documentable.setFilename`); that is,
when the AJAX request started. And so the test passed before the request
was finished, causing the same issue.
Since we're only doing the convertion from bytes to megabytes in one
place, IMHO adding an extra method makes the code harder to read.
This way we don't have do include the DocumentsHelper in the specs
anymore, reducing the risk of possible method naming collisions.
Including them might lead to conflicts since two methods might have the
same name. For example, we're getting some exceptions when taking
screenshots of a failing test, because the method `image_path` from
`ActionView::Helpers::AssetUrlHelper` has the same name as a method used
to save the screenshot.
Besides, we were including all helpers in places were only the `dom_id`
method is used, and in other places where no helper methods were used at
all. So we can just invoke `ActionView::RecordIdentifier.dom_id`
directly.
It looks like sometimes, particularly when the first thing we do after
loading a page is filling the CKEditor fields and submitting the form,
CKEditor doesn't have enough time to format the text, and so it's sent
as plain text instead of HTML. This behaviour can be reproduced on my
local machine after upgrading to Rails 5.1, with the test "Admin Active
polls Add" failing 100% of the time.
Checking CKEditor has been filled in correctly solves the issue.
Checking the whole text is tricky because the text has a `<br>` tag, and
now Capybara doesn't normalize whitespace by default anymore.
Here are a couple more options we could use:
```
expect(page).to have_content strip_tags(message.gsub(/\s*<br>\s*/,"\n"))
expect(page).to have_content strip_tags(message), normalize_ws: true
```
But then developers would wonder why we're doing all this, and would
need an extra effort to fully understand the test.
Since the tests are only checking the presence of the flash message,
checking a relevant part of the test is enough, works with any version
of Capybara, and makes the test easy to follow.
- Validate that locale is a valid locale for RemoteTranslation Client.
- RemoteTranslation can only be created for resources that do not have the requested
language translated
New deutsch translations of remote translations
interface have broke these specs where we were
using English translations at specs to do the checks
while the spec interface was in deutsch and now we
have deutsch translations for the interface application
is not returning english fallbacks anymore and a lot of
specs of this file fails.
This commits also changes the alternative language
used at spec from deutsch to spanish which is
maintaned by code not through Crowdin, so if any
developer update current spanish translations for the
user interface this specs will fail.
Now we do it the same way we attach images in `nested_imageable`.
Now we don't need to execute some JavaScript in the test, which by the
way was causing an error when upgrading to jQuery 3.
The current tracking section had a few issues:
* When browsing as an admin, this section becomes useless since no
investments are shown
* Browsing investments in the admin section, you're suddenly redirected
to the tracking section, making navigation confusing
* One test related to the officing dashboard failed due to these changes
and had been commented
* Several views and controller methods were copied from other sections,
leading to duplication and making the code harder to maintain
* Tracking routes were defined for proposals and legislation processes,
but in the tracking section only investments were shown
* Probably many more things, since these issues were detected after only
an hour reviewing and testing the code
So we're removing this untested section before releasing version 1.1. We
might add it back afterwards.
We were very inconsistent regarding these rules.
Personally I prefer no empty lines around blocks, clases, etc... as
recommended by the Ruby style guide [1], and they're the default values
in rubocop, so those are the settings I'm applying.
The exception is the `private` access modifier, since we were leaving
empty lines around it most of the time. That's the default rubocop rule
as well. Personally I don't have a strong preference about this one.
[1] https://rubystyle.guide/#empty-lines-around-bodies
Having exceptions is better than having silent bugs.
There are a few methods I've kept the same way they were.
The `RelatedContentScore#score_with_opposite` method is a bit peculiar:
it creates scores for both itself and the opposite related content,
which means the opposite related content will try to create the same
scores as well.
We've already got a test to check `Budget::Ballot#add_investment` when
creating a line fails ("Edge case voting a non-elegible investment").
Finally, the method `User#send_oauth_confirmation_instructions` doesn't
update the record when the email address isn't already present, leading
to the test "Try to register with the email of an already existing user,
when an unconfirmed email was provided by oauth" fo fail if we raise an
exception for an invalid user. That's because updating a user's email
doesn't update the database automatically, but instead a confirmation
email is sent.
There are also a few false positives for classes which don't have bang
methods (like the GraphQL classes) or destroying attachments.
For these reasons, I'm adding the rule with a "Refactor" severity,
meaning it's a rule we can break if necessary.
Sanitizing descriptions before saving a record has a few drawbacks:
1. It makes the application rely on data being safe in the database. If
somehow dangerous data enters the database, the application will be
vulnerable to XSS attacks
2. It makes the code complicated
3. It isn't backwards compatible; if we decide to disallow a certain
HTML tag in the future, we'd need to sanitize existing data.
On the other hand, sanitizing the data in the view means we don't need
to triple-check dangerous HTML has already been stripped when we see the
method `auto_link_already_sanitized_html`, since now every time we use
it we sanitize the text in the same line we call this method.
We could also sanitize the data twice, both when saving to the database
and when displaying values in the view. However, doing so wouldn't make
the application safer, since we sanitize text introduced through
textarea fields but we don't sanitize text introduced through input
fields.
Finally, we could also overwrite the `description` method so it
sanitizes the text. But we're already introducing Globalize which
overwrites that method, and overwriting it again is a bit too confusing
in my humble opinion. It can also lead to hard-to-debug behaviour.
Using the `_html` suffix in an i18n key is the same as using `html_safe`
on it, which means that translation could potentially be used for XSS
attacks.
While in theory we wouldn't need to use the `transient` nor the
`after(:create)` because there's already a `has_many :through`
association with followers, Factory Bot / ActiveRecord don't
automatically associate the followable, resulting in an invalid record
exception.
