-
Suggestion
-
Resolution: Unresolved
-
1
-
1
-
Issue Summary
This is reproducible on Data Center: (no)
With the recent introduction of the new UI/UX in Cloud - users can now edit attribute values in-line, while before they had to use an Edit screen.
This, however, allows a user to break an AQL constraint on an Attribute, without any validation to block the action, by editing the dependent attribute in-line, breaking an object's data integrity, and possibly affecting imports.
Steps to Reproduce
- Create two object type; OTA, OTB
- On OTA - add a Status Attribute with the Statuses Closed and Active available
- On OTA - add an Object Type Attribute to reference OTB, with an AQL filter: Label = ${Status}
- Create 2x OTB objects, with labels: "Not Found"; "Running"
- Create an OTA object - notice that if you select Active status, the Active OTB object is select-able, and for "Not Found" the "Not Found" OTB object is select-able.
(At this point lets ignoreJSDCLOUD-12529where if you change the Status in the Create screen - you will still see the previous Status' OTB object available) - Check your object in the new UI>Detail View: an OTA object with Status "Running" referencing the OTB object "Running"
- now change the status of OTA to "Not Found"
- Try to import to update any other attribute on the OTA Objects (e.g. add a text attribute to be populated)
Expected Results
A validation error / notification to indicate that the referenced OTB object
Import should be able to update the object as long as the Attribute's integrity is validated
Actual Results
No warning when the "parent" attribute has changed to indicate that the dependent attribute is violating its configuration.
The Import fails to update the object (correctly) - but without any error, and it does set references to the object (unexpected)!
...
Workaround
Currently thee only workaround is to revert to the old UI.
A workaround will be added here when available
Note:
Previous behavior - using an Edit screen: