- Maintain http headers as JSON-API meta for all API requests (#4946)
- Add EventSource ready for implementing blocking queries
- EventSource project implementation to enable blocking queries for service and node listings (#5267)
- Add setting to enable/disable blocking queries (#5352)
Adds xhr connection managment to http/1.1 installs
This includes various things:
1. An object pool to 'acquire', 'release' and 'dispose' of objects, also
a 'purge' to completely empty it
2. A `Request` data object, mainly for reasoning about the object better
3. A pseudo http 'client' which doens't actually control the request
itself but does help to manage the connections
An initializer is used to detect the script element of the consul-ui sourcecode
which we use later to sniff the protocol that we are most likely using for API access
1. The factory is taken from the ember source, but makes it more
reusable
2. Purify converts conventional ember `computed` into a pure version
This commit only adds new files that could be used further down the line
`window` and `document` are easily injected anyhow, but this
primarily this keeps everything dom related in the same place.
Included here are changes to make all ember related objects use the dom
service `document` and `viewport` instead of just `document` and
`window`.
Quote from a previous PR (#4924) which explains the thinking around this:
> Now I have all these things in the dom service, it would make sense
to get window from there also. I was thinking of making a viewport
method, which would be a nice word whether window was a browser window,
an iframe (not really a window) like when ember testing, or anything
else. To me the viewport is what we are actually talking about here.
1. Ensure any unexpected developer errors are passed through/shown
2. Previously when errors where returns/resolved the special
isEnabled/isAuthorized would never get resolved. This was fine as they
were set to false to start with anyway, but this resolves them again to
false for completeness
3. Improved unit testing coverage
Move all the dom-things to use the dom service in tabular-collection, feedback-dialog, list-collection and node show. Move get-component-factory into utils/dom and use dom.root() in a few more places
This includes an additional `dom.components` method which gives you a
list of components matching the selector instead of just one.
- Adds full set of svg icons as CSS/Sass variables to the source
- Starts picking out some frame-grays, whilst commenting in possibles
- Remove color prefixing
The prefixes `ui-` and `brand-` for colors hav been removed. This makes
colors slightly easier to type.
In order to differentiate between brand colors and 'normal' colors, normal
colors are named as 'true colors' i.e. blue, red, green etc etc
whereas the brand colors used a more premium sounding name such as
'steel' for vault gray, 'magenta' for consul, 'cobalt' for vagrant etc etc.
This does several things to make improving the search experience easier
moving forwards:
1. Separate searching off from filtering. 'Searching' can be thought of
as specifically 'text searching' whilst filtering is more of a
boolean/flag search.
2. Decouple the actual searching functionality to almost pure,
isolated / unit testable units and unit test. (I still import embers get
which, once I upgrade to 3.5, I shouldn't need)
3. Searching rules are now configurable from the outside, i.e. not
wrapped in Controllers or Components.
4. General searching itself now can use an asynchronous approach based on
events. This prepares for future possibilities of handing off the
searching to a web worker or elsewhere, which should aid in large scale
searching and prepares the way for other searching methods.
5. Adds the possibility of have multiple searches in one
template/route/page.
Additionally, this adds a WithSearching mixin to aid linking the
searching to ember in an ember-like way in a single place. Plus a
WithListeners mixin to aid with cleaning up of event listeners on
Controller/Component destruction.
Post-initial work I slightly changed the API of create listeners:
Returning the handler from a `remover` means you can re-add it again if you
want to, this avoids having to save a reference to the handler elsewhere
to do the same.
The `remove` method itself now returns an array of handlers, again you
might want to use these again or something, and its also more useful
then just returning an empty array.
The more I look at this the more I doubt that you'll ever use `remove`
to remove individual handlers, you may aswell just use the `remover`
returned from add. I've added some comments to reflect this, but they'll
likely be removed once I'm absolutely sure of this.
I also added some comments for WithSearching to explain possible further
work re: moving `searchParams` so it can be `hung` off the
controller object
The original version of ember-block-slots doesn't support ember 3 and it
seems like development has stalled on the original version.
This adds a modified version as an in-repo-addon that is compatible with
ember 3.
In 858b05fc31 (diff-46ef88aa04507fb9b039344277531584)
we removed encoding values in pathnames as we thought they were
eventually being encoded by `ember`. It looks like this isn't the case.
Turns out sometimes they are encoded sometimes they aren't. It's complicated.
If at all possible refer to the PR https://github.com/hashicorp/consul/pull/5206.
It's related to the difference between `dynamic` routes and `wildcard` routes.
Partly related to this is a decision on whether we urlencode the slashes within service names or not. Whilst historically we haven't done this, we feel its a good time to change this behaviour, so we'll also be changing services to use dynamic routes instead of wildcard routes. So service links will then look like /ui/dc-1/services/application%2Fservice rather than /ui/dc-1/services/application/service
Here, we define our routes in a declarative format (for the moment at least JSON) outside of Router.map, and loop through this within Router.map to set all our routes using the standard this.route method. We essentially configure our Router from the outside. As this configuration is now done declaratively outside of Router.map we can also make this data available to href-to and paramsFor, allowing us to detect wildcard routes and therefore apply urlencoding/decoding.
Where I mention 'conditionally' below, this is detection is what is used for the decision.
We conditionally add url encoding to the `{{href-to}}` helper/addon. The
reasoning here is, if we are asking for a 'href/url' then whatever we
receive back should always be urlencoded. We've done this by reusing as much
code from the original `ember-href-to` addon as possible, after this
change every call to the `{{href-to}}` helper will be urlencoded.
As all links using `{{href-to}}` are now properly urlencoded. We also
need to decode them in the correct place 'on the other end', so..
We also override the default `Route.paramsFor` method to conditionally decode all
params before passing them to the `Route.model` hook.
Lastly (the revert), as we almost consistently use url params to
construct API calls, we make sure we re-encode any slugs that have been
passed in by the user/developer. The original API for the `createURL`
function was to allow you to pass values that didn't need encoding,
values that **did** need encoding, followed by query params (which again
require url encoding)
All in all this should make the entire ember app url encode/decode safe.
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
John Cowen
John Cowen
Jihoon Chung
Alvin Huang
Hans Hasselberg