open-consul/ui-v2/tests/acceptance/settings/update.feature

@setupApplicationTest
Feature: settings / update: Update Settings
  In order to authenticate with an ACL token
  As a user
  I need to be able to add my token via the UI
  Scenario: I click Save without actually typing anything
    Given 1 datacenter model with the value "datacenter"
    When I visit the settings page
    Then the url should be /settings
    Then I have settings like yaml
    ---
      token: ~
    ---
    And I submit
    Then I have settings like yaml
    ---
      token: ''
    ---
    And the url should be /settings
    And "[data-notification]" has the "notification-update" class
    And "[data-notification]" has the "success" class
Make sure token is set to blank if nothing is typed in settings 2018-06-20 13:38:54 +00:00			`@setupApplicationTest`
			`Feature: settings / update: Update Settings`
			`In order to authenticate with an ACL token`
			`As a user`
			`I need to be able to add my token via the UI`
			`Scenario: I click Save without actually typing anything`
			`Given 1 datacenter model with the value "datacenter"`
			`When I visit the settings page`
			`Then the url should be /settings`
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: ~`
			`---`
Make sure token is set to blank if nothing is typed in settings 2018-06-20 13:38:54 +00:00			`And I submit`
			`Then I have settings like yaml`
			`---`
			`token: ''`
			`---`
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			`And the url should be /settings`
			`And "[data-notification]" has the "notification-update" class`
			`And "[data-notification]" has the "success" class`
Make sure token is set to blank if nothing is typed in settings 2018-06-20 13:38:54 +00:00