Scenario 1-7 all works perfect, so I'll now close the issue as done.
Michal Kuklis July 27, 2017 at 8:17 AM
we had to do some bigger refactoring to support Scenario 7. The work has been done in STCOM-26 and it just got merged. As soon as the new testing env is in place this issue should also be fixed.
Charlotte Whitt July 18, 2017 at 10:49 PM
Np
Michal Kuklis July 18, 2017 at 10:46 PM
Oh I'm sorry I didn't notice this is actually the requirement for this story. I will try to fix it here then.
Michal Kuklis July 18, 2017 at 10:45 PM
We would have to probably make some adjustments to the address component to support it. Do you mind creating a new issue for it? That way we could close this one and I will try to fix it under the new issue.
Purpose: To support library CRUD of address types to be used in the repeatable address field in the user record.
Scenarios:
Scenario
Given Settings > Users
When displayed
Then a Address type page should exist
Scenario
Given the Address type page
When displayed
Then a Address type control should display
Scenario
Given the Address type control
When a new Address type is created
Then Address type name can be specified
Scenario
Given the Address type control
When a new Address type is created
Then it should display in the list of created Address type in Settings
Scenario
Given the Address type control
When a new Address type is deleted
Then it should be removed from the list of created Address type in Settings
Scenario
Given the Address type control
When a new Address type is edited
Then the edits should be reflected in the list of created Address types in Settings
Scenario
Given the Address type control
When I navigate away without saving changes
Then the unsaved changes notification should display per
NOTE: This should use the same component as the one used for Material type and Patron group CRUD