It turns out that the duplicator still raises an exception in some cases. Now I think I see why the the controller was catching the exceptions. At least now we know which exceptions to catch.
Sending large reports via Cable Ready is unreliable. The events are
dropped at an unknown point and the report is never displayed to the
user. Instead we just send a link to the report via Cable Ready and
offer a button to load the report on screen.
This has the UX benefit of warning the user about the size as well.
Weaker devices can struggle rendering big HTML documents.
- Cop: Rails/RedundantActiveRecordAllMethod
- if receiver is an Active Record object, ".all" can be safely removed
- There are 2 allowed receivers that are listed in the
styleguide file (those are defaults cf. cop documentation).
- swap position between users & white label so that user's inner form
- does not interfere with white_label own position in outer form
- modified spec so that lowermost user is clickable
If neither are visible, the first column on the left (eg image) will grow. But that's not a likely scenario.
Min-widths help manage sizes on smaller screens in Chrome.
The title for Inherits Properties gets cut off, but I think it's better than cutting off content.
Oh look, it fixed a spec too!
Capybara should be clever enought to scroll to an element. The old
method failed nine times in CI. I couldn't reproduce it locally but
let's see if this is better.
Visibility was way simpler, but the table doesn't recalculate column widths until you use display:none;
This is now using the same method as the old products screen.
But we still need to update colspans..
The cols could have been a lot cleaner with simple classnames, but I preferred to mark up in a way that reveals the purpose (otherwise they could be used for styling).
It doesn't seem to be any faster comparing querySelector('[data]') vs class, or iterating through the dom nodes.
Moves test on access rights to authentication_spec
The test on accessing the products page as an anonymous does not seem specific to the products page (IMO); as we're testing access rights and the Devise gem (right?) we're probably better off having this test in a more suitable and general context, such as as a spec dealing with authentications and redirects
