luxolus
/
open-consul
2
0
Fork 0
Code Issues 1 Pull Requests Packages Releases Wiki Activity
open-consul/ui/packages/consul-lock-sessions/app/components/consul/lock-session/notifications/index.hbs

46 lines
1.4 KiB
Handlebars
Raw Normal View History

ui: Refactor KV and Lock Sessions following partitions update (#11666) This commit uses all our new ways of doing things to Lock Sessions and their interactions with KV and Nodes. This is mostly around are new under-the-hood things, but also I took the opportunity to upgrade some of the CSS to reuse some of our CSS utils that have been made over the past few months (%csv-list and %horizontal-kv-list). Also added (and worked on existing) documentation for Lock Session related components.
2021-12-01 11:33:33 +00:00
{{#if (eq @type 'remove')}}
{{#if @error}}
<Notice
class="notification-delete"
@type="error"
...attributes
as |notice|>
<notice.Header>
<strong>Error!</strong>
</notice.Header>
<notice.Body>
<p>
There was an error invalidating the Lock Session.
{{#if (and @error.status @error.detail)}}
<br />{{@error.status}}: {{@error.detail}}
{{/if}}
</p>
</notice.Body>
</Notice>
ui: Move all our notification partials to components (#8968)
2020-10-19 16:31:01 +00:00
{{else}}
ui: Refactor KV and Lock Sessions following partitions update (#11666) This commit uses all our new ways of doing things to Lock Sessions and their interactions with KV and Nodes. This is mostly around are new under-the-hood things, but also I took the opportunity to upgrade some of the CSS to reuse some of our CSS utils that have been made over the past few months (%csv-list and %horizontal-kv-list). Also added (and worked on existing) documentation for Lock Session related components.
2021-12-01 11:33:33 +00:00
<Notice
class="notification-delete"
@type="success"
...attributes
as |notice|>
<notice.Header>
<strong>Success!</strong>
</notice.Header>
<notice.Body>
<p>
Your Lock Session has been invalidated.
</p>
</notice.Body>
</Notice>
ui: Move all our notification partials to components (#8968)
2020-10-19 16:31:01 +00:00
{{/if}}
ui: App-ify Lock Sessions (#12482) This commit moves our in-app LockSessions code into an external 'app', which can theoretically be side-loaded but for now it just makes for good isolation/code hygiene. Functionally, there is kind of one change here, and that is we only show the 'Lock Session' tab if you have permissions to see them. Currently as our UI authorization endpoint needs to be changed slightly to suit our usecase, you will always have permissions to see Lock Sessions as we hardcode the session:read to true (obvs this is a frontend thing, not a backend thing), so it doesn't really change anything from a user perspective. Also added very bare docs while I was here. Small note here, ideally we need to add the each individual tab depending on whether an 'app' is enabled or not instead of just permissions, ideally it would be done totally from The Outside rather than a can based conditional on the inside, just something else to be thinking about for the future.
2022-03-14 16:54:49 +00:00
{{else if (eq @type 'kv')}}
feat: update alerts to Hds::Alert component (CC-4035) (#16412)
2023-02-25 04:07:12 +00:00
<Hds::Alert @type='inline' @color='warning' class='mb-3' data-test-session-warning as |A|>
<A.Title>Warning</A.Title>
<A.Description>This KV has a lock session. You can edit KV's with lock sessions, but we recommend doing so with care, or not doing so at all. It may negatively impact the active node it's associated with. See below for more details on the Lock Session.</A.Description>
<A.Link::Standalone @text='Learn more'
@href="{{env 'CONSUL_DOCS_URL'}}/internals/sessions.html"
@icon='docs-link'
@iconPosition='trailing' />
</Hds::Alert>
ui: App-ify Lock Sessions (#12482) This commit moves our in-app LockSessions code into an external 'app', which can theoretically be side-loaded but for now it just makes for good isolation/code hygiene. Functionally, there is kind of one change here, and that is we only show the 'Lock Session' tab if you have permissions to see them. Currently as our UI authorization endpoint needs to be changed slightly to suit our usecase, you will always have permissions to see Lock Sessions as we hardcode the session:read to true (obvs this is a frontend thing, not a backend thing), so it doesn't really change anything from a user perspective. Also added very bare docs while I was here. Small note here, ideally we need to add the each individual tab depending on whether an 'app' is enabled or not instead of just permissions, ideally it would be done totally from The Outside rather than a can based conditional on the inside, just something else to be thinking about for the future.
2022-03-14 16:54:49 +00:00
{{/if}}