Open grantfitzsimmons opened 2 years ago
If back-end does not tell front-end which column an issue occurs in, the front-end can't help but assume that all columns in the table are causing an error
The uniqueness violation can probably be handled better and will probably be part of the improvements to reporting business rule violations. The ambiguity issue though is inherently not related to a single field. Changing any field for a given table could potentially resolve an ambiguity, so there is no way to "assign blame" to a particular field.
To take your locality example, two localities could have the same name but differ in elevation. Adding or changing the elevation value in a row could then remove the ambiguity. So should the locality name field or the elevation field be flagged?
@benanhalt Is there a way to highlight the difference while leaving the other cells errored? It would be useful to see that there is a difference in elevation rather than getting no input on why the ambiguity is happening
Locality Name | Elevation | Elevation Units |
---|---|---|
500m near river | 500 | m |
500m near river | 500 | ft |
In this instance, it would be helpful to see the ft
highlighted
Ignore the poor example, but conceptually what I imagine
@grantfitzsimmons in 2022 had a good idea
Can recreate in edge (7.9.6)
When uploading data in the WorkBench, other fields within a table that needs to be disambiguated or requires a unique identifier (often catalogNumber) will display as error cells.
When a Locality name needs to be disambiguated, every field associated shows as errored. In reality, this should be displayed as something like only the Locality name is an error.
If the catalogNumber is not unique, no other cells referring to the table should show as errors. This has caused issues in several cases, and makes it difficult to troubleshoot where an issue is coming from.