You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Not covered functionality, feature requests, and questions should use the Feature Request or Question templates.
EasyRepro Version
Microsoft Dynamics 365 Online Version 8.2 (8.2.x) (DB 8.2.x) online
Microsoft Dynamics 365 Online Version 9.0 (9.0.x) (DB 9.0.x) online
Microsoft Dynamics 365 Online Version 9.0.2 (9.0.2) (DB 9.0.2) online
Microsoft Dynamics 365 Online Version 9.1 (9.1.x) (DB 9.1.x) online
UCI or Classic Web
UCI (XrmApp)
Classic Web (XrmBrowser)
Online or On Premise
Online
On Premise
Browser
Chrome
Firefox
IE
Edge
Describe the bug
Some attributes should become (non-)mandatory/readonly/writeable depending of another field.
After clearing the initiating field all of them should switch back to their previous state.
Our UI test should check both situations but the Field.IsReadOnly property always returns false.
The form is displaying the expected state correctly.
Special formatting / display
none
Code to reproduce
//Set ProductCode and check if Business Unit and Operating Unit were locked
this.SetLookupValue(Metadata.Lead.ProductCode, "1A Ammonia");
//wraps App.Entity.SetValue(new LookupItem ...
this.ClearFocus();
App.ThinkTime(2000);
IsFieldReadOnly(Metadata.Lead.BusinessUnit, true); // does not work properly
IsFieldReadOnly(Metadata.Lead.OperatingUnit, true); // does not work properly
...
public void IsFieldReadOnly(string attributeName, bool expectedValue)
{
this.TestContext.WriteLine("IsFieldReadOnly: {0}", attributeName);
Field field = this.App.Entity.GetField(attributeName);
if (expectedValue)
{
Assert.IsTrue(field.IsReadOnly);
}
else
{
Assert.IsFalse(field.IsReadOnly);
}
}
Expected behavior
Field.IsReadOnly (also IsRequired and IsVisible) should return the current state that is displayed on the form.
Screenshots
Previous state
After setting "Product Code"
Result of Assert
Additional context
In this case it occurs on lookup fields only. The depending field is the "Product Code", that should lock both fields above if set.
The text was updated successfully, but these errors were encountered:
In another case a lookup is initially readonly. The first request of Field.IsReadOnly works fine. After switching to writeable and back to readonly Field.IsReadOnly does not return the correct state for the lookup. All other fields that are not of type lookup are working fine.
Bug Report
Issues should only be created for items related to covered functionality.
Not covered functionality, feature requests, and questions should use the Feature Request or Question templates.
EasyRepro Version
UCI or Classic Web
Online or On Premise
Browser
Describe the bug
Some attributes should become (non-)mandatory/readonly/writeable depending of another field.
After clearing the initiating field all of them should switch back to their previous state.
Our UI test should check both situations but the Field.IsReadOnly property always returns false.
The form is displaying the expected state correctly.
Special formatting / display
none
Code to reproduce
Expected behavior
Field.IsReadOnly (also IsRequired and IsVisible) should return the current state that is displayed on the form.
Screenshots
Previous state
After setting "Product Code"
Result of Assert
Additional context
In this case it occurs on lookup fields only. The depending field is the "Product Code", that should lock both fields above if set.
The text was updated successfully, but these errors were encountered: