We were using a <ul> tag for a single comment, where the first element
of the list was the comment itself and the second element was the list
of replies.
IMHO it makes more sense to have a list of all comments, where every
element is a comment and inside it there's a list of replies.
We're also rendering the list even if it has no children so it's easier
to add comments through JavaScript. Then we use the :empty CSS selector
to hide the list if it's empty. However, since ERB adds whitespace if we
structure our code the usual way and current browsers don't recognize
elements with whitespace as empty, we have to use the `tag` helper so no
whitespace is added.
Tests are also a bit easier to read, even though we need to use the
`text:` option to find links because otherwise the text in the hidden
`<span>` tags will cause `click_link` to miss the link we want to click.
Here's an explanation by one of Capybara's authors:
https://github.com/teamcapybara/capybara/issues/2347#issuecomment-626373440
We were passing around many variables to condition the way we display
the comment. However, in the end we only had one place where these
variables were used: valuation. So we can make everything depend on the
valuation variable.
It was created in commit 83d254ad, but it was never used, since the
commit creating it removed the code rendering the
`budgets/investments/comments` partial, which this partial was supposed
to replace.
When a page with ckeditor is restored from browser cache by using browser
history back feature application was trying to re-initialize it but this was
throwing some javascript errors that left ckeditor useless. The ckeditor user
interface seemed to be loaded correctly but editor contents was not shown
and ckeditor locked.
This solution is about destroying all ckeditor instances on page before
leaving it and force the reinitialization after Turbolinks restored the cache.
Inspiration here [1].
There is a similar patch to make it work with Turbolinks 5.x versions [2].
[1] https://github.com/galetahub/ckeditor/issues/575#issuecomment-132757961
[2] https://github.com/galetahub/ckeditor/issues/575#issuecomment-241185136
We were calling initialize_modules after every ajax call only to apply the
application javascript to new elements added though ajax calls, this is not
always needed because some ajax calls do not add new elements to the user
interface so there is no new elements to initialize. This technique was working
fine in most cases but was causing different kind of problems at some pages where
some elements where being unnecessarily reinitiliazed causing the execution of the
element associated scripts as many times as the element was initialized. This fix
should relief a little bit of work to users browsers.
After this change we had to fix some pieces of javascript:
Regarding LegistationAnnotatable module, since we are not re-initializing Annotator
app we cannot destroy it so now we only need to insert the new annotation into annotator
interface to keep it properly updated.
Regarding Comments module, we do not need anymore the initialization check because this
code only will be fired once now we do not launch application initialization after ajax
calls. Also, when a new comment is created its added to the DOM through AJAX and include
some elements that needs javascript initialization to work. By using
"Delegated event handlers" [1] new comments will be initialized automatically when added.
[1] https://api.jquery.com/on/#direct-and-delegated-events
The method `available_locales` in
`RemoteTranslations::Microsoft::AvailableLocales` needs to execute a
request to an external server in order to work, meaning it will fail if
the machine its executed on doesn't have an internet connection.
So we're stubbing the method in the tests using it.
We were evaluating its value when the server starts. On production
enviroments, that could mean weeks or months before the available
locales are checked again, and so it would be possible to use a list
which is no longer in sync with the list provided by microsoft.
Back in commit 49e55b4d we lowered its severity because there were a
few false positives. Back then, I didn't realize we could just whitelist
the methods causing false positives.
Thanks taitus for the tip.
I incorrectly used "text" as variable name in commit 2cdc6a1b. In
similar places, we use `label`. We also use named parameters when only
`with:` is provided.
Some specs involving CKEditor were failing sometimes in the Rails 5.1
branch. The reason why these specs pass with Rails 5.0 but fail with
Rails 5.1 are unknown. On my machine the tests pass when precompiling
the assets, which makes me think it's related to the way Rails handles
them, but it might have nothing to do with it.
The only (apparently) 100% reliable solution I've found is to wait for
CKEditor to load before trying to fill it in. After running the tests on
my machine hundreds of time, I didn't get a single failure.
There are two reasons for this change:
1. Past migrations depending on models will not work once a model is
removed, and they won't work if we remove Globalize either
2. We were getting a conflict in the schema file; when run under Rails
5.0, these migrations were generating a different schema than in Rails
5.1, due to the way the `create_translation_table!` method handles the
`id: :serial` attribute.
Using `render :nothing` was deprecated, but we never noticed it because
we didn't have a test for the action using it. In Rails 5.1, it raises
an exception.
Using `head :ok` and adding a test for this scenario solves the issue.
CKEditor repositions the dialog to attach an image after showing it. If
its position changes right when Capybara is trying to click the "Upload"
link, the click does not work properly.
I haven't found a way to check the dialog has stopped moving, so I've
chosen to force its position to the top.
Without this change, this test failed a lot on my machine when using
Rails 5.1, both with an "iframe ckeditor" and an "inline ckeditor".
However, it didn't fail when using Rails 5.0.
Rails 5.1 updated the `method_source` dependency, which is incompatible
with pry 0.12.x (which some developers are using), and upgrading pry and
pry-byebug requires a more recent version of byebug.
Since we use transactions now for every test, we can seed the database
at the beginning, and then it will go back to this state before a test
is executed.
Running the test suite is now considerably faster. On my machine, we
save a quarter of second per system test, meaning we save several
minutes for the whole suite.
We were manually setting `http://www.example.com`. However, Capybara now
uses `http://127.0.0.1`.
While we could change the code to use `127.0.0.1`, I think directly
using `Capybara.app_host` makes it easier to realize what the code is
doing. And, particularly, now it's clear the host has nothing to do with
our `Setting["url"]`, which by default points to `www.example.com` as
well.
This method is deprecated in Rails 5.1 because its behavior will be
different in `before` and `after` callbacks.
We're replacing the deprecated `attribute_changed?` and `attribute_was`
methods with `saved_change_to_attribute?` and
`attribute_before_last_save` during `after_save` callbacks.
https://github.com/rails/rails/pull/32835/
This method is deprecated in Rails 5.1 because its behavior will be
different in `before` and `after` callbacks.
Here we're replacing the deprecated `attribute_changed?` and
`attribute_was` with `will_save_change_to_attribute?` and
`attribute_in_database` during `before_save` callbacks.
https://github.com/rails/rails/pull/32835/
Rails 5.1 introduced certain changes in the way a record is touched when
the counter cache option is enabled in a belongs to association.
We need to upgrade acts-as-taggable-on so it keeps changing the
`updated_at` attribute when a new tag is added to a record.
Note we now need to reload the records in some cases to get the
`context_tag_list` method to return what we expect. Methods like
`context_tags` however work properly with no need to reload the record.