In order to continue supporting the legacy ACL system, we replace
the 500 error from a non-existent `self` endpoint with a response of a
`null` `AccessorID` - which makes sense (a null AccessorID means old
API)
We then redirect the user to the old ACL pages which then gives a 403
if their token was wrong which then redirects them back to the login page.
Due to the multiple redirects and not wanting to test the validity of the token
before redirecting (thus calling the same API endpoint twice), it is not
straightforwards to turn the 'faked' response from the `self` endpoint
into an error (flash messages are 'lost' through multiple redirects).
In order to make this a slightly better experience, you can now return a
`false` during execution of an action requiring success/failure
feedback, this essentially skips the notification, so if the action is
'successful' but you don't want to show the notification, you can. This
resolves showing a successful notification when the `self` endpoint
response is faked. The last part of the puzzle is to make sure that the
global 403 catching error in the application Route also produces an
erroneous notification.
Please note this can only happen with a ui client using the new ACL
system when communicating with a cluster using the old ACL system, and
only when you enter the wrong token.
Lastly, further acceptance tests have been added around this
This commit also adds functionality to avoid any possible double
notification messages, to avoid UI overlapping
In some circumstances a consul 1.4 client could be running in an
un-upgraded 1.3 or lower cluster. Currently this gives a 500 error on
the new ACL token endpoint. Here we catch this specific 500 error/message
and set the users AccessorID to null. Elsewhere in the frontend we use
this fact (AccessorID being null) to decide whether to present the
legacy or the new ACL UI to the user.
Also:
- Re-adds in most of the old style ACL acceptance tests, now that we are keeping the old style UI
- Restricts code editors to HCL only mode for all `Rules` editing (legacy/'half legacy'/new style)
- Adds a [Stop using] button to the old style ACL rows so its possible to logout.
- Updates copy and documentation links for the upgrade notices
1. Unskip some trivial tests that were being tested higher up
2. Istanbul ignore some code for coverage.
1. Things that I didn't write and need to 100% follow
2. The source code checking test that has Istanbul code injected into
it
3. Add a few simple test cases
4. Support passing port numbers through to `ember serve` and `ember
test` for use cases that would benefit from being able to configure the
ports things are served over but still use `yarn run` thus reusing the
`yarn run` config in `package.json`
Repositories are a class of services to help with CRUD actions, most of
the functionality is reused across various Models. This creates a new
repository service that centralizes all this reused functionality.
Inheritance via ember `Service.extend` is used as opposed to
decorating via Mixins.
1. Move all repository services (and their tests) to a
services/repository folder
2. Standardize on a singular name format 'node vs nodes'
3. Create a new 'repository' service to centralize functionality. This
should be extended by 'repository' services
Essentially this was missing a call to `super`. The error unfortuantely
didn't arise in the tests as it only errors when the node list has 4
items are more (the 4 columns), and the acceptence tests by change were
only filling the page with 3 nodes for test purposes.
I've bumped the amount of nodes up to 4 in the tests, which then causes
the tests to fail, made the fix by adding the `super` call, and the
tests now pass.
I also tested the UI/text searching on a 10,000 node system, and
everything now works as expected.
Upgrade all patch and minor upgradeable packages, also uses `only`
in ember-cli-build to reduce the included helpers from certain helper
packages.
Make some major version upgrades for some dev tools
- husky
- lint-staged
- ember-cli-yadda
- ember-cli-sass (also moved from node-sass to dart-sass)
Minor tweak: spotted css file (instead of scss file), rename
The move to `dart-sass`:
dart-sass has been the primary implementation of sass for ~6 months and
will receive updates earlier than libsass (ruby-sass itself is now deprecated)
Other benefits include not having to recompile (via `npm rebuild` or similar)
when switching platforms and an 'almost' javascript based solution.
This update also alters some media queries that, whilst wouldn't compile
anymore with either an updated libsass or dart-sass, where probably a
little over complicated anyway, I've therefore made them similar to
other breakpoints that made sense.
Various ember addons produced deprecation messages, some in the browser
console and some in terminal. Upgrading and replacing some of these has
reduced this.
Upgrades:
- ember-collection
- ember-computed-style
Replacements:
- ember-pluralize replaced with ember-inflector
- ember-cli-format-number replaced with custom helper using standard
`toLocaleString`
Removing ember-cli-format-number also meant some further changes related
to decimal places in the tomography graph, done using `toFixed`
The ExternalSources background-images have also now been escaped
correctly preventing in-development `console` warnings.
The only deprecation warnings are now from ember-block-slots, only in
terminal, making for a better development experience overall, especially now we
have an empty browser console
Also adds a `callIfType` 'helper util' which is a util specifically for helpers (it conforms to a helper argument signature) to be expanded upon later.
Having the code editor on removes the text area from the DOM, making it
more difficult to enter text in the text editor during testing. This
turns the code editor off whilst making edits during testing.
No changes to UI code
The mocks where using randomly generated `ExternalSources` this change
makes sure they are fixed so we can reliably test the values. No change
to actual UI code
The error notification was being shown on creation of an intention. This
was as a result of #4572 and/or #4572 and has not been included in a
release.
This includes a fix, plus tests to try to prevent any further regression.
1. Addition of external source icons for services marked as such.
2. New %with-tooltip css component (wip)
3. New 'no healthcheck' icon as external sources might not have
healthchecks, also minus icon on node cards in the service detail view
4. If a service doesn't have healthchecks, we use the [Services] tabs as the
default instead of the [Health Checks] tab in the Service detail page.
5. `css-var` helper. The idea here is that it will eventually be
replaced with pure css custom properties instead of having to use JS. It
would be nice to be able to build the css variables into the JS at build
time (you'd probably still want to specify in config which variables you
wanted available in JS), but that's possible future work.
Lastly there is probably a tiny bit more testing edits here than usual,
I noticed that there was an area where the dynamic mocking wasn't
happening, it was just using the mocks from consul-api-double, the mocks
I was 'dynamically' setting happened to be the same as the ones in
consul-api-double. I've fixed this here also but it wasn't effecting
anything until actually made certain values dynamic.
* Move notification texts to a slightly different layer (#4572)
* Further Simplify/refactor the actions/notification layer (#4573)
1. Move the 'with-feedback' actions to a 'with-blocking-action' mixin
which better describes what it does
2. Additional set of unit tests almost over the entire layer to prove
things work/add confidence for further changes
The multiple 'with-action' mixins used for every 'index/edit' combo are
now reduced down to only contain the functionality related to their
specific routes, i.e. where to redirect.
The actual functionality to block and carry out the action and then
notify are 'almost' split out so that their respective classes/objects do
one thing and one thing 'well'.
Mixins are chosen for the moment as the decoration approach used by
mixins feels better than multiple levels of inheritence, but I would
like to take this fuether in the future to a 'compositional' based
approach.
There is still possible further work to be done here, but I'm a lot
happier now this is reduced down into separate parts.
ui: Repo layer integration tests for methods that touch the API
Includes a `repo` test helper to make repetitive tasks easier, plus a
injectable reporter for sending performance metrics to a centralized metrics
system
Also noticed somewhere in the ember models that I'd like to improve, but left
for the moment to make sure I concentrate on one task at a time, more or less:
The tests currently asserts against the existing JSON tree, which doesn't
seem to be a very nice tree.
The work at hand here is to refactor what is there, so test for the not
nice tree to ensure we don't get any regression, and add a skipped test
so I can come back here later
WIP Unskip some lower level trivial tests.
This is the beginning of work to unskip some of the more trivial tests that I'd skipped a while back (if the thing they are testing broke, they would have failed higher up in other acceptance tests).
I'd rather keep the tests, as they do test things in a more isolated manner, and the plan was to always come back and work to unskip them time allowing.
I didn't get to far into this work in progress here, but I'd rather merge what I've done all the same and come back at a later date and continue.
1. Split the resizing functionality of into a separate mixin to be
shared across components
2. Add basic integration tests to prove that everything is getting
called through out the lifetime of the app. I decided against unit
testing as there isn't really any isolated logic to be tested, more
checking that things are being called in the correct order etc i.e. the
integration is correct.
Adds assertion to with-resizing so its obvious to override `resize`
* Add some tests to check the correct GET API endpoints are called
* Refactor adapters
1. Add integration tests for `urlFor...` and majority `handleResponse` methods
2. Refactor out `handleResponse` a little more into single/batch/boolean
methods
3. Move setting of the `Datacenter` property into the `handleResponse`
method, basically the same place that the uid is being set using the dc
parsed form the URL
4. Add some Errors for if you don't pass ids to certain `urlFor` methods
We now essentially do 2 redirects if you hit a `folder/`
1. If you visit `/ui/dc1/kv/folder/`, `consul` will redirect you to `/ui/dc1/kv/folder`
2. Once redirected to `/ui/dc1/kv/folder` via a 301, use ember/history
API to redirect you back to `/ui/dc1/kv/folder/`.
Bit long winded, but achieves what we want without having to get stuck
into `consul` itself to remove the 301 for the UI
The Consul API can pass through `Value: null` which does not get cast to
a string by ember-data. This snowballs into problems with `atob` which
then tried to decode `null`.
There are 2 problems here.
1. `Value` should never be `null`
- I've added a removeNull function to shallowly loop though props and
remove properties that are `null`, for the moment this is only on
single KV JSON responses - therefore `Value` will never be `null`
which is the root of the problem
2. `atob` doesn't quite follow the `window.atob` API in that the
`window.atob` API casts everything down to a string first, therefore it
will try to decode `null` > `'null'` > `crazy unicode thing`.
- I've commented in a fix for this, but whilst this shouldn't be
causing anymore problems in our UI (now that `Value` is never `null`),
I'll uncomment it in another future release. Tests are already written
for it which more closely follow `window.atob` but skipped for now
(next commit)
1. There are various things tests that can just have intentions added
into them, like filters and such like, add intentions to these
2. Start thinking about being able to negate steps easily, which will
lead on to a cleanup of the steps
This enables people to enter things using the mouse to paste for
example, plus possible other things.
As an aside it also answers my query regarding `fillIn` for testing,
nothing needs to be actually _typed_ anymore! Doh
Previously `api-double` usage in ember would require a bunch of `fetch`
requests to pull in the 'api double', this had a number of disadvantages.
1. The doubles needed to be available via HTTP, which meant a short term
solution of rsyncing the double files over to `public` in order to be served
over HTTP. An alternative to that would have been figuring out how to serve
something straight from `node_modules`, which would have been preferable.
2. ember/testem would not serve dot files (so anything starting with a
., like `.config`. To solve this via ember/testem would have involved
digging in to understand how to enable the serving of dot files.
3. ember/testem automatically rewrote urls for non-existant files to
folders, i.e. adding a slash for you, so `/v1/connect/intentions` would
be rewritten to `/v1/connect/intentions/`. This is undesirable, and
solving this via ember/testem would have involved digging deep to
disable that.
Serving the files via HTTP has now changed. The double files are now
embedded into the HTML has 'embedded templates' that can be found by
using the url of the file and a simple `querySelector`. This of course
only happens during testing and means I can fully control the 'serving'
of the doubles now, so I can say goodbye to the need to move files
around, worry about the need to serve dotfiles and the undesirable
trailing slashes rewriting. Winner!
Find the files and embedding them is done using a straightforward
recursive-readdir-sync (the `content-for` functionality is a synchronous
api) as oppose to getting stuck into `broccoli`.
John Cowen
John Cowen
mkeeler