Fix start page not being honoured

[GilbertCherrie]

Fixes: #9513

Fixes the issue with the start page in the settings being saved but not actually working when logging into the application.

[miq-bot]

Checked commit GilbertCherrie@b4052f8 with ruby 3.1.7, rubocop 1.56.3, haml-lint 0.64.0, and yamllint
0 files checked, 0 offenses detected
Everything looks fine. ⭐

[GilbertCherrie]

Also, I found issues with some of the shortcuts. These are all fixed in this pr: ManageIQ/manageiq#23515

[jrafanie]

@GilbertCherrie looks good to me. Can you write a test to get the current start page, set the start page, and revert it back to the original start page?

I think this fix may improve test speed if we change the default start page to a faster page like utilization. Of course, our tests would need to know how to correctly navigate the page and not rely on login landing you on a specific page.

[jrafanie]

@GilbertCherrie looks good to me. Can you write a test to get the current start page, set the start page, and revert it back to the original start page?

I think this fix may improve test speed if we change the default start page to a faster page like utilization. Of course, our tests would need to know how to correctly navigate the page and not rely on login landing you on a specific page.

@GilbertCherrie If the login redirect hits the API for the /api/users/X for the settings, you might be able to test this by using fixtures to stub the result so you don't need to pollute other tests by setting the start page. In other words, you can fake that response with different values from the API GET to make sure the login direct puts it on the right start page.

See #9489 where I give an example of intercept + responding with a fixture.

[Fryguy]

@asirvadAbrahamVarghese Please also review.

[GilbertCherrie]

@Fryguy @jrafanie I fixed the time waits by replacing them with intercepts.

[jrafanie]

LGTM so far... Just had a minor comment above.

[jrafanie]

What do we do if there's no match? I feel like it should fail, otherwise tests could silently continue on and we wouldn't realize we had a typo or something in the name of the option or something similar.

[jrafanie]

@asirvadAbrahamVarghese didn't you have recent examples like this? Do you have any suggestions?

[asirvadAbrahamVarghese]

Correct, the test won’t fail by default here, we must explicitly throw an error when no match occurs, like in this PR:9531

[jrafanie]

@GilbertCherrie was this changed so a non-match would throw like in #9531?

[GilbertCherrie]

@jrafanie fixed it now

[jrafanie]

LGTM. I see we do something similar in simulation.cy.js... we might want to refactor these... cc @asirvadAbrahamVarghese not sure if you want to take a look at this later on...

% git grep -i list-box__menu-item__option cypress
cypress/e2e/ui/Embedded-Automate/simulation.cy.js:      cy.get('[class="bx--list-box__menu-item__option"]').contains('User').click({force: true});
cypress/e2e/ui/Embedded-Automate/simulation.cy.js:      cy.get('[class="bx--list-box__menu-item__option"]').contains('User').click({force: true});
cypress/e2e/ui/Embedded-Automate/simulation.cy.js:      cy.get('[class="bx--list-box__menu-item__option"]').contains('User').click({force: true});

2. Determine if there's any shared code we can reuse from toolbarItems. I don't know if selecting options is the same for the different components but it feels like they might be similar...

cypress/support/commands/toolbar.js:Cypress.Commands.add('toolbarItems', (toolbarButton) => {
cypress/support/commands/toolbar.js-  cy.toolbar(toolbarButton);
cypress/support/commands/toolbar.js-  const dropdownButtons = [];
cypress/support/commands/toolbar.js-  cy.get('.bx--overflow-menu-options').then((tempButtons) => {
cypress/support/commands/toolbar.js-    let buttons = tempButtons.children();
cypress/support/commands/toolbar.js-    const nums = [...Array(buttons.length).keys()];
cypress/support/commands/toolbar.js-    nums.forEach((index) => {
cypress/support/commands/toolbar.js-      const tempButton = buttons[index].children[0];
cypress/support/commands/toolbar.js-      dropdownButtons.push({
cypress/support/commands/toolbar.js-        text: tempButton.innerText.trim(),
cypress/support/commands/toolbar.js-        disabled: tempButton.disabled,
cypress/support/commands/toolbar.js-        button: tempButton,
cypress/support/commands/toolbar.js-      });
cypress/support/commands/toolbar.js-    });
cypress/support/commands/toolbar.js-    return dropdownButtons;
cypress/support/commands/toolbar.js-  });
cypress/support/commands/toolbar.js-});

[asirvadAbrahamVarghese]

Looks like cy.toolbarItems is used to grab all toolbar options, which are identified by the bx--overflow-menu-options class:

The bx--list-box__menu-item__option class appears to represent combobox options (but I’m not sure if it’s unique throughout the app):

We probably can't use cy.toolbarItems in this case, as it targets a different selector. I beleive cypress/support/commands/select.js is intended for this

[jrafanie]

@GilbertCherrie is this ready for re-review? thanks!

[GilbertCherrie]

@jrafanie yeah it is

[jrafanie]

the user id 1 will change... do we care about intercepting that specifically or can we use a more generic intercept regex?

[GilbertCherrie]

Isn't user 1 for admin?

[jrafanie]

No, that's based on id which could is an auto incremented number. It's unlikely to change since we have a check_reference validation so it won't let you delete a user associated to requests, widgets or templates... but the id is not guaranteed to be 1...

Below, I show admin is user id 1, I destroy it, I seed the User class again to create the admin user again. It now has id 4.

% bin/rails c --sandbox
vmdb(prod)> User.select(:id, :userid)
=> [#<User:0x000000012a41e8a0 id: 1, userid: "admin">]
vmdb(prod)> u = User.first; u.destroy; User.seed; nil
=> nil
vmdb(prod)> User.select(:id, :userid)
=> [#<User:0x00000001370a58d8 id: 4, userid: "admin">]

[asirvadAbrahamVarghese]

May be we can use cy.logAndThrowError here