1. You only need the fixtures for testing, don't force rsync on people
for just building
2. Eventually this will go and be replaced by something broccoli-y
Tables need to calculate their sizing depending on other things in the
DOM. When a table is in a tab panel, some of these things aren't visible
and therefore some values are zero during `didInsertElement`.
This commit ensures that the resize calc of the table is performed when
it's parent tab is clicked (and therefore when the table 'appears')
It's not obvious what "the way" to teardown window event handlers is in
Ember. The datacenter-picker is permanently in the app during usage, but
in tests I'm assuming it gets added and removed lots.
So when you run the tests, as the tests aren't run in an isolated runner
the QUnit test runner ends up with a click handler on it, So if you
click on the test runner one of the tests will fail.
The failure is related to there not being an element with a `.contains`
method. So this checks that the element is truthy first, i.e. it exists.
If it doesn't it just bails out.
1. Calculate where group is going to be, if it will get cut off, then
dropup instead of down
2. As the action group can now drop up, the z-index should be higher
than the previous rows, so add a top z-index higher than the others and
use that when opened
As the input field was used for KV's it looked like you couldn't save
multiline KV's. Changed to textarea so you can see the multilines.
Also, JSON is slightly misleading as clicking the toggle doesn't
necessarily mean 'I'm going to edit some JSON' it means I want the code
editor with syntax highlighting, so renamed the toggle to say 'Code'
This has an explcit unit test already which somehow passes at least some of the time. I suspect it passes because under some conditions the actual KV delete fails and returns non-zero as well as printing the warning which is what is being checked for in the test.
For some reason despite working for quite some time like this, I now have a branch in which this test fails consistently. It may be a timing/env issue where another process running an agent causes the delete to be successful so the command returns a 0 by chance. Either way this is clearly wrong and fixing it stops the test being flaky in my branch.
John Cowen