-
Notifications
You must be signed in to change notification settings - Fork 365
Bypass feature validation for dynamic tenant features #9523
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Bypass feature validation for dynamic tenant features #9523
Conversation
As discussed
|
Closing in favor of #9527 |
c8c8ee5
to
c816791
Compare
c816791
to
6484ca9
Compare
cc @asirvadAbrahamVarghese I used some of your pre-canned functions for the cypress test - let me know if you have better options than what I used. |
cy.toolbar(toolBarConfigMenu, 'Add child Tenant to this Tenant'); | ||
cy.get('input#name').type(initialTenantName); | ||
cy.get('input#description').type(initialTenantDescription); | ||
cy.contains('.bx--btn--primary', 'Add').click(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
if this is a form can you try using getFormFooterButtonByType
cy.getFormFooterButtonByType('Add', 'submit')
should work (not sure about the html button type here)
]); | ||
|
||
cy.toolbar(toolBarConfigMenu, 'Add child Tenant to this Tenant'); | ||
cy.get('input#name').type(initialTenantName); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Here we can use getFormInputFieldById
cy.getFormInputFieldById('name').type(initialTenantName);
should be good.
|
||
cy.toolbar(toolBarConfigMenu, 'Add child Tenant to this Tenant'); | ||
cy.get('input#name').type(initialTenantName); | ||
cy.get('input#description').type(initialTenantDescription); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
similar to above: cy.getFormInputFieldById('description').type(initialTenantDescription);
I haven't come across many form elements yet, but using these commands consistently across tests will help us generalize the selectors in here 😃 |
// flash message assertions | ||
flashMessageOperationAdded: 'added', | ||
flashMessageOperationDeleted: 'delete', | ||
flashTypeSuccess: 'success', |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I wanted to use a constant for the flash message type to avoid repetition, but forgot to follow through: #9554
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'll do that here and update collect_logs as well
6484ca9
to
f601874
Compare
@@ -195,7 +192,7 @@ function saveButtonValidation() { | |||
.should('be.enabled') | |||
.click(); | |||
// Validating confirmation flash message | |||
cy.expect_flash(flashTypeSuccess, flashMessageSettingsSaved); | |||
cy.expect_flash(flashClassMap.success, flashMessageSettingsSaved); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I changed this one too...
@asirvadAbrahamVarghese please take a look at the test changes... I also reduced the repetitive constant definition and assignment. |
@jrafanie looks fine to me now, thanks! |
// CRUD actions | ||
const FLASH_MESSAGE_OPERATION_ADDED = 'added'; | ||
const FLASH_MESSAGE_OPERATION_DELETED = 'delete'; | ||
const DELETE_ITEM = 'Delete this item'; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This list of constants can be updated/consolidated when we add more access control tests. It's hard to decide what should be constants vs. inline.
My thinking is:
- If it's used in a selector and unique to the test, it probably should be left as an inline string to make the test more readable. If it's used often enough, it should should become a shared function.
- Simple text we input for CRUD will likely be reused by other tests so constants make sense there
- Shared navigation for the whole set of tests and not unique to the test could be constants...
I don't know, that's my thinking here.
@Fryguy can you review the ruby side here? This is the workaround for the per tenant feature thing. |
We expect a one to one feature assignment with existing product features. This doesn't work with dynamic tenant features. This dynamic tenant feature was only ever implemented for tenant quotas. Related to: ManageIQ#5123 ManageIQ#5129 ManageIQ#5142 Fixes: ManageIQ#9512
This recreates the issue found in ManageIQ#9512
* Drop repetive constant definition and assignment * Generalize the names of constants * Capitalize constants as per conventions
f601874
to
6f11925
Compare
Rebase/Updated after dropping the edit collect logs changes that were also in #9546, which was merged cc @asirvadAbrahamVarghese |
Backported to
|
…n-for-tenant-dynamic-product-features Bypass feature validation for dynamic tenant features (cherry picked from commit 71881e1)
Bypass feature validation for dynamic tenant features
We expect a one to one feature assignment with existing product features.
This doesn't work with dynamic tenant features.
This dynamic tenant feature was only ever implemented for tenant quotas.
Related to:
#5123
#5129
#5142
Fixes: #9512
Add a test for Settings, Access Control, Tenant Add and Delete
This recreates the issue found in #9512