We were getting a warning: "Checking for expected text of nil is
confusing and/or pointless since it will always match. Please specify a
string or regexp instead" because we were checking for values which were
set to `nil` in the tests.
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.
Implementation tries to be open for further extensions, such as deciding on
search dictionary based on configuration option or by locale set for
given user.
The method `tag_list_on` doesn't add an `ORDER_BY` clause to the SQL
query it generates, and so results may come in any order.
However, in the tests we were assuming the tags were ordered by ID in
descending order. Since that isn't always the case, the tests were
failing sometimes.
Ordering the tags alphabetically solves the problem. We could also use
the same order admins used when adding the tags:
```
@process.customs.order("taggings.created_at").pluck(:name).join(", ")
```
However, I'm not sure it improves the user experience, and it makes the
code more complicated.
benefit to administratos.
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.
When an investment had been assigned a user tag and a valuation tag with
the same name, it appeared twice when filtering by tag.
This is because by design, in order to provide compatibility with scopes
using "select" or "distinct", the method `tagged_with` doesn't select
unique records.
Forcing the query to return unique records solves the issue.
The following code:
```
<span class="show-for-sr">You're on page</span> 1
```
Will generate an element with `position: absolute`. When reading the
contents, it's not clear whether this element is supposed to be in the
same paragraph or in a different one. Currently Capybara treats it as
if it were part of a different paragraph.
Since this could be the way screen readers read the text, I'm changing
the test to reflect this fact. We might change our minds in the future.
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.
With the rack driver, the `ballot_sheet.data` text was being converted
from newline characters to whitespace, while with the JavaScript driver
we get newline characters for `<br>` tags, as we expect.
In this spec, we were doing to request at the same time; one to unselect
an investment and another one to filter the investments. If the second
request finished before the first one, the test failed.
Adding an expectation to check the first request has finished before the
second one starts solves the problem.
Legislation::Proposal is not Globalize model but use CommentableActions and try
detect remote translations. Add new condition to discard Non Globalize models.
This fix is necessary since the following commit was included: c1f3a4ad.
- 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
In the admin menu, some links take you to a section, and some links open
a submenu with more links.
When we disable the "multi-open" property of the menu and the active
element is a link which takes you to a section, Foundation will hide it
whenever we click a link which opens a submenu.
The easiest solution is to enable "multi-open" property.
Since now it's possible to edit the budget investment during the
accepting phase, it does not really make sense to show the button to
just remove the image when the investment project can be fully edited,
and the image can be removed from the editing form.
These filters were only returning investments with valuation open, but
we don't want to do that since the time we changed the interface in
order to allow users to apply several filters at the same time.
To maintain consistency and the use of advanced search in the frontend,
we forced the expected date format for all languages. This is a temporary
solution that we should analyze in depth to allow different date formats
depending on the language in the filters.
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.
