* ui: Acceptance test improvements to prepare for more NS tests
* ui: Namespace acceptance testing (#7005)
* Update api-double and consul-api-double for http.body
* Adds places where we missed passing the nspace through
* Hardcode nspace CRUD to use the default nspace for policies and roles
* Alter test helpers to allow us to control nspaces from the outside
* Amends to allow tests to account for namespace, move ns from queryParam
1. We decided to move how we pass the namespace value through to the
backend when performing write actions (create, update). Previoulsy we
were using the queryParam although using the post body is the preferred
method to send the Namespace details through to the backend.
2. Other various amends to take into account testing across multiple
namespaced scenarios
* Enable nspace testing by default
* Remove last few occurances of old style http assertions
We had informally 'deprecated' our old style of http assertions that
relied on the order of http calls (even though that order was not
important for the assertion). Following on from our namespace work we
removed the majority of the old occrances of these old style assertions.
This commit removes the remaining few, and also then cleans up the
assertions/http.js file to only include the ones we are using.
This reduces our available step count further and prevents any confusion
over the usage of the old types and the new types.
* ui: Namespace CRUD acceptance tests (#7016)
* Upgrade consul-api-double
* Add all the things required for testing:
1. edit and index page objects
2. enable CONSUL_NSPACE_COUNT cookie setting
3. enable mutating HTTP response bodies based on URL
* Add acceptance test for nspace edit/delete/list and searching
Adds namespace support to the UI:
1. Namespace CRUD/management
2. Show Namespace in relevant areas (intentions, upstreams)
3. Main navigation bar improvements
4. Logic/integration to interact with a new `internal/acl/authorize` endpoint
-Enable blocking queries by default
-Change assertion to check for the last PUT request, not just any request for session destruction from a node page.
Since we've now turned on blocking queries by default this means that a
second GET request is made after the PUT request that we are asserting
for but before the assertion itself, this meant the assertion failed. We
double checked this by turning off blocking queries for this test using
```
And settings from yaml
---
consul:client:
blocking: 0
---
```
which made the test pass again.
As moving forwards blocking queries will be on by default, we didn't
want to disable blocking queries for this test, so we now assert the
last PUT request specifically. This means we continue to assert that the
session has been destroyed but means we don't get into problems of
ordering of requests here
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.
John Cowen