Skip to content
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

bug fixes #707

Merged
merged 2 commits into from
Jan 10, 2020
Merged

bug fixes #707

merged 2 commits into from
Jan 10, 2020

Conversation

KhoaAN
Copy link

@KhoaAN KhoaAN commented Jan 9, 2020

Type of change

  • Bug fix (non-breaking change which fixes an issue)
  • New feature (non-breaking change which adds functionality)
  • Other (updates to documentation, formatting, etc.)

Description

Latest version of EasyRepro introduced a new bug #702 while trying to fix #620 . The new bug is to do with Quick Create form not working for Lookup fields. The fix for this is to sort of undo the changes for the fix of bug #620 .
This pull request also include a fix for bug #684 where the quick create form elements not interactable due to the page having 2 fields with the same data-id (1 from quick create and 1 from the main entity). This issue happened because the codes only look for the first element on the page using a given data-id. It would find the one on the main page for creating/editing this entity record instead of the one from Quick Create. To address this issue, we have to find all elements matching the given data-id and check for the one that is visible on the screen.

Issues addressed

This would fix the issue with Lookup field on Quick Create form and not causing bug #620 to be recreated.
The fix for bug #684 would make the Quick Create form works perfectly for that specific case and any other cases.

All submissions:

  • My code follows the code style of this project.
  • Do existing samples that are effected by this change still run?
  • I have added samples for new functionality.
  • I raise detailed error messages when possible.
  • My code does not rely on labels that have the option to be hidden.

Which browsers was this tested on?

  • Chrome
  • Firefox
  • IE
  • Edge

@msftclas
Copy link

msftclas commented Jan 9, 2020

CLA assistant check
All CLA requirements met.

Copy link
Author

@KhoaAN KhoaAN left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@TYLEROL Can you please review the PR?

@TYLEROL TYLEROL added the bug label Jan 10, 2020
@TYLEROL TYLEROL added this to the 9.1.0.11711 milestone Jan 10, 2020
@TYLEROL TYLEROL merged commit 9e2a745 into microsoft:develop Jan 10, 2020
@KhoaAN
Copy link
Author

KhoaAN commented Jan 13, 2020

@TYLEROL @dtu11
Thanks to you guys for publishing the new version so quickly.

@@ -588,8 +588,15 @@ public static IWebElement WaitUntilAvailable(this IWebDriver driver, By by, Time

try
{
returnElement = wait.Until(d => d.FindElement(by));

var foundElements = wait.Until(d => d.FindElements(by));
Copy link
Contributor

@AngelRodriguez8008 AngelRodriguez8008 Jan 18, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

[UPDATED] There is a problem hier, if you call FindElements if the element is not already loaded, you will get an Empty Collection but not NULL. That's means you will not really "wait", see the implementation of wait.Until:
image

For me fail at Login Dialog by "Enter Email"
To get the desired Effect you need to do something like that:

Func<IWebDriver, IWebElement> conditions = d =>
{
    ReadOnlyCollection<IWebElement> elements = d.FindElements(by);
    int? count = elements?.Count;
    if (count == null || count == 0)
        return null;

    var result = count > 1
        ? elements.FirstOrDefault(x => x?.Displayed == true)
        : elements.First(x => x != null);
    
    return result;
};
returnElement  = wait.Until(conditions);

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hi AngelRodriguez8008,
Sorry I haven't been checking github and i've moved on from doing automated testing for D365.
Your previous post showed great explanation to the root of the issue. Can you please refactor the codes and apply the fix for it because you can test the login dialog issue. I did have some random UCI login issue few weeks ago but it was inconsistent (1 issue out of 5 runs sort of thing) so I didn't look into it.
If you want me to do it, i'll need to spend sometime setting up D365 classic web app and test the codes. Let me know what you wanna do. Cheers

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hi @KhoaAN, I already fixed it in two PRs (#735, #747)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

[BUG] Set value for a lookup is selecting the field on the header
5 participants