open-consul/ui-v2/tests/acceptance/dc/acls/use.feature

@setupApplicationTest
@ignore
Feature: dc / acls / use: Using an ACL token
  Background:
    Given 1 datacenter model with the value "datacenter"
    And 1 acl model from yaml
    ---
      ID: token
    ---
  Scenario: Using an ACL token from the listing page
    When I visit the acls page for yaml
    ---
      dc: datacenter
    ---
    Then I have settings like yaml
    ---
      token: ~
    ---
    And I click actions on the acls
    And I click use on the acls
    And I click confirmUse on the acls
    Then "[data-notification]" has the "notification-use" class
    And "[data-notification]" has the "success" class
    Then I have settings like yaml
    ---
      token: token
    ---
  Scenario: Using an ACL token from the detail page
    When I visit the acl page for yaml
    ---
      dc: datacenter
      acl: token
    ---
    Then I have settings like yaml
    ---
      token: ~
    ---
    And I click use
    And I click confirmUse
    Then "[data-notification]" has the "notification-use" class
    And "[data-notification]" has the "success" class
    Then I have settings like yaml
    ---
      token: token
    ---
Acceptance test for using tokens from listing and detail pages 2018-07-04 15:37:41 +00:00			`@setupApplicationTest`
UI: New ACLs (#4789) UI to accompany the new ACLs APIs 2018-10-19 15:17:02 +00:00			`@ignore`
Acceptance test for using tokens from listing and detail pages 2018-07-04 15:37:41 +00:00			`Feature: dc / acls / use: Using an ACL token`
			`Background:`
			`Given 1 datacenter model with the value "datacenter"`
			`And 1 acl model from yaml`
			`---`
			`ID: token`
			`---`
			`Scenario: Using an ACL token from the listing page`
			`When I visit the acls page for yaml`
			`---`
			`dc: datacenter`
			`---`
			`Then I have settings like yaml`
			`---`
			`token: ~`
			`---`
			`And I click actions on the acls`
			`And I click use on the acls`
			`And I click confirmUse on the acls`
UI: Simplify/refactor the actions/notification layer (#4572) + (#4573) * Move notification texts to a slightly different layer (#4572) * Further Simplify/refactor the actions/notification layer (#4573) 1. Move the 'with-feedback' actions to a 'with-blocking-action' mixin which better describes what it does 2. Additional set of unit tests almost over the entire layer to prove things work/add confidence for further changes The multiple 'with-action' mixins used for every 'index/edit' combo are now reduced down to only contain the functionality related to their specific routes, i.e. where to redirect. The actual functionality to block and carry out the action and then notify are 'almost' split out so that their respective classes/objects do one thing and one thing 'well'. Mixins are chosen for the moment as the decoration approach used by mixins feels better than multiple levels of inheritence, but I would like to take this fuether in the future to a 'compositional' based approach. There is still possible further work to be done here, but I'm a lot happier now this is reduced down into separate parts. 2018-08-29 18:14:31 +00:00			`Then "[data-notification]" has the "notification-use" class`
			`And "[data-notification]" has the "success" class`
Acceptance test for using tokens from listing and detail pages 2018-07-04 15:37:41 +00:00			`Then I have settings like yaml`
			`---`
			`token: token`
			`---`
			`Scenario: Using an ACL token from the detail page`
			`When I visit the acl page for yaml`
			`---`
			`dc: datacenter`
			`acl: token`
			`---`
			`Then I have settings like yaml`
			`---`
			`token: ~`
			`---`
			`And I click use`
			`And I click confirmUse`
UI: Simplify/refactor the actions/notification layer (#4572) + (#4573) * Move notification texts to a slightly different layer (#4572) * Further Simplify/refactor the actions/notification layer (#4573) 1. Move the 'with-feedback' actions to a 'with-blocking-action' mixin which better describes what it does 2. Additional set of unit tests almost over the entire layer to prove things work/add confidence for further changes The multiple 'with-action' mixins used for every 'index/edit' combo are now reduced down to only contain the functionality related to their specific routes, i.e. where to redirect. The actual functionality to block and carry out the action and then notify are 'almost' split out so that their respective classes/objects do one thing and one thing 'well'. Mixins are chosen for the moment as the decoration approach used by mixins feels better than multiple levels of inheritence, but I would like to take this fuether in the future to a 'compositional' based approach. There is still possible further work to be done here, but I'm a lot happier now this is reduced down into separate parts. 2018-08-29 18:14:31 +00:00			`Then "[data-notification]" has the "notification-use" class`
			`And "[data-notification]" has the "success" class`
Acceptance test for using tokens from listing and detail pages 2018-07-04 15:37:41 +00:00			`Then I have settings like yaml`
			`---`
			`token: token`
			`---`