luxolus
/
open-consul
2
0
Fork 0
Code Issues 1 Pull Requests Packages Releases Wiki Activity
open-consul/ui/packages/consul-ui/tests/acceptance/dc/intentions/permissions/warn.feature

32 lines
980 B
Gherkin
Raw Normal View History

ui: Intention "Action change" warning modal (#9108) * ui: Add a warning dialog if you go to remove permissions from an intention * ui: Move modal styles next to component, add warning style * ui: Move back to using the input name for a selector * ui: Fixup negative "isn't" step so its optional * Add warning modal to pageobject * Fixup test for whether to show the warning modal or not * Intention change action warning acceptence test * Add a null/undefined Action
2020-11-06 14:57:19 +00:00
@setupApplicationTest
Feature: dc / intentions / permissions / warn: Intention Permission Warn
Scenario:
Given 1 datacenter model with the value "datacenter"
And 1 intention model from yaml
---
SourceNS: default
SourceName: web
DestinationNS: default
DestinationName: db
Action: ~
Permissions:
- Action: allow
HTTP:
PathExact: /path
---
When I visit the intention page for yaml
---
dc: datacenter
intention: intention-id
---
Then the url should be /datacenter/intentions/intention-id
ui: a11y modals (#9819) This PR uses the excellent a11y-dialog to implement our modal functionality across the UI. This package covers all our a11y needs - overlay click and ESC to close, controlling aria-* attributes, focus trap and restore. It's also very small (1.6kb) and has good DOM and JS APIs and also seems to be widely used and well tested. There is one downside to using this, and that is: We made use of a very handy characteristic of the relationship between HTML labels and inputs in order to implement our modals previously. Adding a for="id" attribute to a label meant you can control an <input id="id" /> from anywhere else in the page without having to pass javascript objects around. It's just based on using the same string for the for attribute and the id attribute. This allowed us to easily open our login dialog with CSS from anywhere within the UI without having to manage passing around a javascript object/function/method in order to open the dialog. We've PRed #9813 which includes an approach which would make passing around JS modal object easier to do. But in the meantime we've added a little 'hack' here using an additional <input /> element and a change listener which allows us to keep this label/input characteristic of our old modals. I'd originally thought this would be a temporary amend in order to wait on #9813 but the more I think about it, the more I think its quite a nice thing to keep - so longer term we may/may not keep this.
2021-03-09 09:30:01 +00:00
And I click ".value-deny"
ui: Intention "Action change" warning modal (#9108) * ui: Add a warning dialog if you go to remove permissions from an intention * ui: Move modal styles next to component, add warning style * ui: Move back to using the input name for a selector * ui: Fixup negative "isn't" step so its optional * Add warning modal to pageobject * Fixup test for whether to show the warning modal or not * Intention change action warning acceptence test * Add a null/undefined Action
2020-11-06 14:57:19 +00:00
And I submit
ui: a11y modals (#9819) This PR uses the excellent a11y-dialog to implement our modal functionality across the UI. This package covers all our a11y needs - overlay click and ESC to close, controlling aria-* attributes, focus trap and restore. It's also very small (1.6kb) and has good DOM and JS APIs and also seems to be widely used and well tested. There is one downside to using this, and that is: We made use of a very handy characteristic of the relationship between HTML labels and inputs in order to implement our modals previously. Adding a for="id" attribute to a label meant you can control an <input id="id" /> from anywhere else in the page without having to pass javascript objects around. It's just based on using the same string for the for attribute and the id attribute. This allowed us to easily open our login dialog with CSS from anywhere within the UI without having to manage passing around a javascript object/function/method in order to open the dialog. We've PRed #9813 which includes an approach which would make passing around JS modal object easier to do. But in the meantime we've added a little 'hack' here using an additional <input /> element and a change listener which allows us to keep this label/input characteristic of our old modals. I'd originally thought this would be a temporary amend in order to wait on #9813 but the more I think about it, the more I think its quite a nice thing to keep - so longer term we may/may not keep this.
2021-03-09 09:30:01 +00:00
And I see the warning object
ui: Intention "Action change" warning modal (#9108) * ui: Add a warning dialog if you go to remove permissions from an intention * ui: Move modal styles next to component, add warning style * ui: Move back to using the input name for a selector * ui: Fixup negative "isn't" step so its optional * Add warning modal to pageobject * Fixup test for whether to show the warning modal or not * Intention change action warning acceptence test * Add a null/undefined Action
2020-11-06 14:57:19 +00:00
And I click the warning.cancel object
ui: a11y modals (#9819) This PR uses the excellent a11y-dialog to implement our modal functionality across the UI. This package covers all our a11y needs - overlay click and ESC to close, controlling aria-* attributes, focus trap and restore. It's also very small (1.6kb) and has good DOM and JS APIs and also seems to be widely used and well tested. There is one downside to using this, and that is: We made use of a very handy characteristic of the relationship between HTML labels and inputs in order to implement our modals previously. Adding a for="id" attribute to a label meant you can control an <input id="id" /> from anywhere else in the page without having to pass javascript objects around. It's just based on using the same string for the for attribute and the id attribute. This allowed us to easily open our login dialog with CSS from anywhere within the UI without having to manage passing around a javascript object/function/method in order to open the dialog. We've PRed #9813 which includes an approach which would make passing around JS modal object easier to do. But in the meantime we've added a little 'hack' here using an additional <input /> element and a change listener which allows us to keep this label/input characteristic of our old modals. I'd originally thought this would be a temporary amend in order to wait on #9813 but the more I think about it, the more I think its quite a nice thing to keep - so longer term we may/may not keep this.
2021-03-09 09:30:01 +00:00
And I don't see the warning object
ui: Intention "Action change" warning modal (#9108) * ui: Add a warning dialog if you go to remove permissions from an intention * ui: Move modal styles next to component, add warning style * ui: Move back to using the input name for a selector * ui: Fixup negative "isn't" step so its optional * Add warning modal to pageobject * Fixup test for whether to show the warning modal or not * Intention change action warning acceptence test * Add a null/undefined Action
2020-11-06 14:57:19 +00:00
And I submit
ui: a11y modals (#9819) This PR uses the excellent a11y-dialog to implement our modal functionality across the UI. This package covers all our a11y needs - overlay click and ESC to close, controlling aria-* attributes, focus trap and restore. It's also very small (1.6kb) and has good DOM and JS APIs and also seems to be widely used and well tested. There is one downside to using this, and that is: We made use of a very handy characteristic of the relationship between HTML labels and inputs in order to implement our modals previously. Adding a for="id" attribute to a label meant you can control an <input id="id" /> from anywhere else in the page without having to pass javascript objects around. It's just based on using the same string for the for attribute and the id attribute. This allowed us to easily open our login dialog with CSS from anywhere within the UI without having to manage passing around a javascript object/function/method in order to open the dialog. We've PRed #9813 which includes an approach which would make passing around JS modal object easier to do. But in the meantime we've added a little 'hack' here using an additional <input /> element and a change listener which allows us to keep this label/input characteristic of our old modals. I'd originally thought this would be a temporary amend in order to wait on #9813 but the more I think about it, the more I think its quite a nice thing to keep - so longer term we may/may not keep this.
2021-03-09 09:30:01 +00:00
And I see the warning object
ui: Intention "Action change" warning modal (#9108) * ui: Add a warning dialog if you go to remove permissions from an intention * ui: Move modal styles next to component, add warning style * ui: Move back to using the input name for a selector * ui: Fixup negative "isn't" step so its optional * Add warning modal to pageobject * Fixup test for whether to show the warning modal or not * Intention change action warning acceptence test * Add a null/undefined Action
2020-11-06 14:57:19 +00:00
And I click the warning.confirm object
Then a PUT request was made to "/v1/connect/intentions/exact?source=default%2Fweb&destination=default%2Fdb&dc=datacenter" from yaml