consul/ui/packages/consul-ui/tests/acceptance/dc/intentions/create.feature

106 lines
4.1 KiB
Gherkin
Raw Normal View History

@setupApplicationTest
Feature: dc / intentions / create: Intention Create
In order to define intentions
As a user
I want to visit the intention create page, fill in the form and hit the create button and see a success notification
@onlyNamespaceable
Scenario: with namespaces enabled
Given 1 datacenter model with the value "datacenter"
And 3 service models from yaml
---
- Name: web
Kind: ~
- Name: db
Kind: ~
- Name: cache
Kind: ~
---
ui: [BUGFIX] Re-enable namespace menus whilst editing intentions (#11095) This PR supersedes #10706 and fixes #10686 whilst making sure that saving intentions continues to work. The original fix in #10706 ignored the change action configured for the change event on the menus, meaning that the selected source/destination namespace could not be set by the user when editing/creating intentions. This, coupled with the fact that using the later intention exact endpoint for API requests endpoint means that you could not use wildcard namespaces for saving intentions. All in all this meant that intentions could no longer be saved using the UI (whilst using ENT) This PR reverts #10706 to fix the intention saving issue, and adds a fix for the original visual issue of nspaces doubling up in the menu once clicked. This meant repeating the existing functionality for nspaces aswell as services. It did seem strange to me that the original issue was only apparent for the nspace menus and not the service menus which should all function exactly the same way. There is potentially more to come here partly related to what the exact functionality should be, but I'm working with other folks to figure out what the best way forwards is longer term. In the meantime this brings us back to the original functionality with the visual issue fixed. Squashed commits: * Revert "ui: Fix dropdown option duplications (#10706)" This reverts commit eb5512fb74781ea49be743e2f0f16b3f1863ef61. * ui: Ensure additional nspaces are added to the unique list of nspaces * Add some acceptance tests
2021-09-22 09:21:20 +00:00
And 1 nspace model from yaml
---
- Name: nspace-0
---
When I visit the intention page for yaml
---
dc: datacenter
---
Then the url should be /datacenter/intentions/create
And the title should be "New Intention - Consul"
# Set source
And I click "[data-test-source-element] .ember-power-select-trigger"
And I type "web" into ".ember-power-select-search-input"
And I click ".ember-power-select-option:first-child"
Then I see the text "web" in "[data-test-source-element] .ember-power-select-selected-item"
# Set destination
And I click "[data-test-destination-element] .ember-power-select-trigger"
And I type "db" into ".ember-power-select-search-input"
And I click ".ember-power-select-option:first-child"
Then I see the text "db" in "[data-test-destination-element] .ember-power-select-selected-item"
ui: [BUGFIX] Re-enable namespace menus whilst editing intentions (#11095) This PR supersedes #10706 and fixes #10686 whilst making sure that saving intentions continues to work. The original fix in #10706 ignored the change action configured for the change event on the menus, meaning that the selected source/destination namespace could not be set by the user when editing/creating intentions. This, coupled with the fact that using the later intention exact endpoint for API requests endpoint means that you could not use wildcard namespaces for saving intentions. All in all this meant that intentions could no longer be saved using the UI (whilst using ENT) This PR reverts #10706 to fix the intention saving issue, and adds a fix for the original visual issue of nspaces doubling up in the menu once clicked. This meant repeating the existing functionality for nspaces aswell as services. It did seem strange to me that the original issue was only apparent for the nspace menus and not the service menus which should all function exactly the same way. There is potentially more to come here partly related to what the exact functionality should be, but I'm working with other folks to figure out what the best way forwards is longer term. In the meantime this brings us back to the original functionality with the visual issue fixed. Squashed commits: * Revert "ui: Fix dropdown option duplications (#10706)" This reverts commit eb5512fb74781ea49be743e2f0f16b3f1863ef61. * ui: Ensure additional nspaces are added to the unique list of nspaces * Add some acceptance tests
2021-09-22 09:21:20 +00:00
# Set source nspace
And I click "[data-test-source-nspace] .ember-power-select-trigger"
And I click ".ember-power-select-option:last-child"
ui: [BUGFIX] Re-enable namespace menus whilst editing intentions (#11095) This PR supersedes #10706 and fixes #10686 whilst making sure that saving intentions continues to work. The original fix in #10706 ignored the change action configured for the change event on the menus, meaning that the selected source/destination namespace could not be set by the user when editing/creating intentions. This, coupled with the fact that using the later intention exact endpoint for API requests endpoint means that you could not use wildcard namespaces for saving intentions. All in all this meant that intentions could no longer be saved using the UI (whilst using ENT) This PR reverts #10706 to fix the intention saving issue, and adds a fix for the original visual issue of nspaces doubling up in the menu once clicked. This meant repeating the existing functionality for nspaces aswell as services. It did seem strange to me that the original issue was only apparent for the nspace menus and not the service menus which should all function exactly the same way. There is potentially more to come here partly related to what the exact functionality should be, but I'm working with other folks to figure out what the best way forwards is longer term. In the meantime this brings us back to the original functionality with the visual issue fixed. Squashed commits: * Revert "ui: Fix dropdown option duplications (#10706)" This reverts commit eb5512fb74781ea49be743e2f0f16b3f1863ef61. * ui: Ensure additional nspaces are added to the unique list of nspaces * Add some acceptance tests
2021-09-22 09:21:20 +00:00
Then I see the text "nspace-0" in "[data-test-source-nspace] .ember-power-select-selected-item"
# Set destination nspace
And I click "[data-test-destination-nspace] .ember-power-select-trigger"
And I click ".ember-power-select-option:last-child"
ui: [BUGFIX] Re-enable namespace menus whilst editing intentions (#11095) This PR supersedes #10706 and fixes #10686 whilst making sure that saving intentions continues to work. The original fix in #10706 ignored the change action configured for the change event on the menus, meaning that the selected source/destination namespace could not be set by the user when editing/creating intentions. This, coupled with the fact that using the later intention exact endpoint for API requests endpoint means that you could not use wildcard namespaces for saving intentions. All in all this meant that intentions could no longer be saved using the UI (whilst using ENT) This PR reverts #10706 to fix the intention saving issue, and adds a fix for the original visual issue of nspaces doubling up in the menu once clicked. This meant repeating the existing functionality for nspaces aswell as services. It did seem strange to me that the original issue was only apparent for the nspace menus and not the service menus which should all function exactly the same way. There is potentially more to come here partly related to what the exact functionality should be, but I'm working with other folks to figure out what the best way forwards is longer term. In the meantime this brings us back to the original functionality with the visual issue fixed. Squashed commits: * Revert "ui: Fix dropdown option duplications (#10706)" This reverts commit eb5512fb74781ea49be743e2f0f16b3f1863ef61. * ui: Ensure additional nspaces are added to the unique list of nspaces * Add some acceptance tests
2021-09-22 09:21:20 +00:00
Then I see the text "nspace-0" in "[data-test-destination-nspace] .ember-power-select-selected-item"
# Specifically set deny
2021-03-09 09:30:01 +00:00
And I click ".value-deny"
And I submit
Then a PUT request was made to "/v1/connect/intentions/exact?source=default%2Fnspace-0%2Fweb&destination=default%2Fnspace-0%2Fdb&dc=datacenter" from yaml
ui: [BUGFIX] Re-enable namespace menus whilst editing intentions (#11095) This PR supersedes #10706 and fixes #10686 whilst making sure that saving intentions continues to work. The original fix in #10706 ignored the change action configured for the change event on the menus, meaning that the selected source/destination namespace could not be set by the user when editing/creating intentions. This, coupled with the fact that using the later intention exact endpoint for API requests endpoint means that you could not use wildcard namespaces for saving intentions. All in all this meant that intentions could no longer be saved using the UI (whilst using ENT) This PR reverts #10706 to fix the intention saving issue, and adds a fix for the original visual issue of nspaces doubling up in the menu once clicked. This meant repeating the existing functionality for nspaces aswell as services. It did seem strange to me that the original issue was only apparent for the nspace menus and not the service menus which should all function exactly the same way. There is potentially more to come here partly related to what the exact functionality should be, but I'm working with other folks to figure out what the best way forwards is longer term. In the meantime this brings us back to the original functionality with the visual issue fixed. Squashed commits: * Revert "ui: Fix dropdown option duplications (#10706)" This reverts commit eb5512fb74781ea49be743e2f0f16b3f1863ef61. * ui: Ensure additional nspaces are added to the unique list of nspaces * Add some acceptance tests
2021-09-22 09:21:20 +00:00
---
body:
SourceName: web
DestinationName: db
SourceNS: nspace-0
DestinationNS: nspace-0
SourcePartition: default
DestinationPartition: default
ui: [BUGFIX] Re-enable namespace menus whilst editing intentions (#11095) This PR supersedes #10706 and fixes #10686 whilst making sure that saving intentions continues to work. The original fix in #10706 ignored the change action configured for the change event on the menus, meaning that the selected source/destination namespace could not be set by the user when editing/creating intentions. This, coupled with the fact that using the later intention exact endpoint for API requests endpoint means that you could not use wildcard namespaces for saving intentions. All in all this meant that intentions could no longer be saved using the UI (whilst using ENT) This PR reverts #10706 to fix the intention saving issue, and adds a fix for the original visual issue of nspaces doubling up in the menu once clicked. This meant repeating the existing functionality for nspaces aswell as services. It did seem strange to me that the original issue was only apparent for the nspace menus and not the service menus which should all function exactly the same way. There is potentially more to come here partly related to what the exact functionality should be, but I'm working with other folks to figure out what the best way forwards is longer term. In the meantime this brings us back to the original functionality with the visual issue fixed. Squashed commits: * Revert "ui: Fix dropdown option duplications (#10706)" This reverts commit eb5512fb74781ea49be743e2f0f16b3f1863ef61. * ui: Ensure additional nspaces are added to the unique list of nspaces * Add some acceptance tests
2021-09-22 09:21:20 +00:00
Action: deny
---
Then the url should be /datacenter/intentions
And the title should be "Intentions - Consul"
And "[data-notification]" has the "notification-update" class
And "[data-notification]" has the "success" class
@notNamespaceable
Scenario: with namespaces disabled
Given 1 datacenter model with the value "datacenter"
And 3 service models from yaml
---
- Name: web
Kind: ~
- Name: db
Kind: ~
- Name: cache
Kind: ~
---
When I visit the intention page for yaml
---
dc: datacenter
---
Then the url should be /datacenter/intentions/create
And the title should be "New Intention - Consul"
# Set source
And I click "[data-test-source-element] .ember-power-select-trigger"
And I type "web" into ".ember-power-select-search-input"
And I click ".ember-power-select-option:first-child"
Then I see the text "web" in "[data-test-source-element] .ember-power-select-selected-item"
# Set destination
And I click "[data-test-destination-element] .ember-power-select-trigger"
And I type "db" into ".ember-power-select-search-input"
And I click ".ember-power-select-option:first-child"
Then I see the text "db" in "[data-test-destination-element] .ember-power-select-selected-item"
# Specifically set deny
2021-03-09 09:30:01 +00:00
And I click ".value-deny"
And I submit
Then a PUT request was made to "/v1/connect/intentions/exact?source=default%2Fdefault%2Fweb&destination=default%2Fdefault%2Fdb&dc=datacenter" from yaml
---
body:
SourceName: web
DestinationName: db
Action: deny
---
Then the url should be /datacenter/intentions
And the title should be "Intentions - Consul"
And "[data-notification]" has the "notification-update" class
And "[data-notification]" has the "success" class