2020-01-28 14:25:52 +00:00
{{ # if isAuthorized }}
{{ title 'Tokens' }}
{{ else }}
{{ title 'Access Controls' }}
{{ / if }}
2020-07-29 13:41:40 +00:00
2020-08-11 17:02:51 +00:00
{{ # let ( or sortBy "CreateTime:desc" ) as | sort | }}
2020-04-08 17:03:18 +00:00
<AppView
@class="token list"
@loading= {{ isLoading }}
@authorized= {{ isAuthorized }}
@enabled= {{ isEnabled }}
>
2020-02-19 19:26:38 +00:00
<BlockSlot @name="notification" as |status type subject|>
ui: Async Search (#4859)
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
2018-11-06 09:10:20 +00:00
{{ partial 'dc/acls/tokens/notifications' }}
2020-02-19 19:26:38 +00:00
</BlockSlot>
<BlockSlot @name="header">
ui: Async Search (#4859)
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
2018-11-06 09:10:20 +00:00
<h1>
Access Controls
</h1>
2020-05-07 13:57:15 +00:00
</BlockSlot>
<BlockSlot @name="nav">
ui: Async Search (#4859)
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
2018-11-06 09:10:20 +00:00
{{ # if isAuthorized }}
{{ partial 'dc/acls/nav' }}
{{ / if }}
2020-02-19 19:26:38 +00:00
</BlockSlot>
<BlockSlot @name="disabled">
ui: Async Search (#4859)
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
2018-11-06 09:10:20 +00:00
{{ partial 'dc/acls/disabled' }}
2020-02-19 19:26:38 +00:00
</BlockSlot>
<BlockSlot @name="authorization">
ui: Async Search (#4859)
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
2018-11-06 09:10:20 +00:00
{{ partial 'dc/acls/authorization' }}
2020-02-19 19:26:38 +00:00
</BlockSlot>
<BlockSlot @name="actions">
ui: Async Search (#4859)
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
2018-11-06 09:10:20 +00:00
<a data-test-create href=" {{ href-to 'dc.acls.tokens.create' }} " class="type-create">Create</a>
2020-02-19 19:26:38 +00:00
</BlockSlot>
2020-07-29 13:41:40 +00:00
<BlockSlot @name="toolbar">
{{ # if ( gt items .length 0 ) }}
2020-08-11 17:02:51 +00:00
<SearchBar
@value= {{ search }}
@onsearch= {{ action ( mut search ) value = "target.value" }}
class="with-sort"
>
<BlockSlot @name="secondary">
<PopoverSelect
@position="right"
@onchange= {{ action ( mut sortBy ) value = 'target.selected' }}
@multiple= {{ false }}
as |components|>
<BlockSlot @name="selected">
<span>
{{ # let ( from-entries ( array
(array "CreateTime:desc" "Newest to oldest")
(array "CreateTime:asc" "Oldest to newest")
))
as |selectable|
}}
{{ get selectable sort }}
{{ / let }}
</span>
</BlockSlot>
<BlockSlot @name="options">
{{ # let components .Optgroup components .Option as | Optgroup Option | }}
<Optgroup @label="Creation">
<Option @value="CreateTime:desc" @selected= {{ eq "CreateTime:desc" sort }} >Newest to oldest</Option>
<Option @value="CreateTime:asc" @selected= {{ eq "CreateTime:asc" sort }} >Oldest to newest</Option>
</Optgroup>
{{ / let }}
</BlockSlot>
</PopoverSelect>
</BlockSlot>
</SearchBar>
2020-07-29 13:41:40 +00:00
{{ / if }}
</BlockSlot>
<BlockSlot @name="content">
ui: Async Search (#4859)
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
2018-11-06 09:10:20 +00:00
{{ # if ( token / is-legacy items ) }}
2019-08-05 17:10:00 +00:00
<p data-test-notification-update class="notice info"><strong>Update.</strong> We have upgraded our ACL System to allow the creation of reusable policies that can be applied to tokens. Read more about the changes and how to upgrade legacy tokens in our <a href=" {{ env 'CONSUL_DOCS_URL' }} /guides/acl-migrate-tokens.html" target="_blank" rel="noopener noreferrer">documentation</a>.</p>
ui: Async Search (#4859)
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
2018-11-06 09:10:20 +00:00
{{ / if }}
2020-08-11 17:02:51 +00:00
{{ # let ( sort-by ( comparator 'token' sort ) items ) as | sorted | }}
2020-07-29 13:41:40 +00:00
<ChangeableSet @dispatcher= {{ searchable 'token' sorted }} @terms= {{ search }} >
2020-02-19 19:26:38 +00:00
<BlockSlot @name="set" as |filtered|>
2020-06-17 09:25:54 +00:00
<ConsulTokenList
2020-07-29 13:41:40 +00:00
@items= {{ filtered }}
2020-06-17 09:25:54 +00:00
@token= {{ token }}
@onuse= {{ action send 'use' }}
@ondelete= {{ action send 'delete' }}
@onlogout= {{ action send 'logout' }}
@onclone= {{ action send 'clone' }}
/>
</BlockSlot>
<BlockSlot @name="empty">
<EmptyState @allowLogin= {{ true }} >
2020-02-19 19:26:38 +00:00
<BlockSlot @name="header">
2020-06-17 09:25:54 +00:00
<h2>
{{ # if ( gt items .length 0 ) }}
No tokens found
{{ else }}
Welcome to ACL Tokens
{{ / if }}
</h2>
2020-02-19 19:26:38 +00:00
</BlockSlot>
2020-06-17 09:25:54 +00:00
<BlockSlot @name="body">
<p>
{{ # if ( gt items .length 0 ) }}
No tokens where found matching that search, or you may not have access to view the tokens you are searching for.
{{ else }}
There don't seem to be any tokens, or you may not have access to view tokens yet.
{{ / if }}
</p>
2020-02-19 19:26:38 +00:00
</BlockSlot>
2020-06-17 09:25:54 +00:00
</EmptyState>
2020-02-19 19:26:38 +00:00
</BlockSlot>
</ChangeableSet>
2020-07-29 13:41:40 +00:00
{{ / let }}
2020-02-19 19:26:38 +00:00
</BlockSlot>
</AppView>
2020-07-29 13:41:40 +00:00
{{ / let }}
