Consistent Table Headers and/or Add Preference

[bronwyncombs]

Is your feature request related to a problem? Please describe.
A clear and concise description of what the problem is. Ex. I'm always frustrated when [...]

In 7.9.3.1 we see seemingly random additions of table names in query outputs. In the screenshots below, one of the locality fields shows as locality.datum, the other ones only have the field name. Ditto with the Geo Coord Details and CO.

We find this behaviour (i.e., the inconsistency) really confusing and assume this will be the same for our end-users. In fact, I was just talking with someone in the insect collection yesterday and she really did not like this approach at all...

Describe the solution you'd like
A clear and concise description of what you want to happen.

Is this something that could be made a user preference? Otherwise it would be more consistent to just add the table name to every field (though I suspect that will also not be the preferred option for many people as it will clutter things up).

I can see how this may be helpful if a query has say multiple instances of a Notes/Remarks field,

but the examples above are short queries where there is no 'multiples' of the fields within the query itself. Also, the second example shows the catalognumber field with the table name - I can't see more than one field with that name in the schema?

To add a further example here. I've just had a play with a Workbench template. I have two agent fields (Host and Visitor) yet the headers differentiate only by adding a (2) to the WB header fields. Until I get to the address components at that point I see the 'Visitor' prefix. The 'Visitor Log Event' prefixes in the last two fields seem completely unnecessary as neither of these two Captions appear elsewhere in the WB template. And lastly, slightly off-topic, the two date fields highlighted in blue do not pull in the caption of the field but show the Specify field name.

Reported By
Corinna @ CSIRO on Asana

Additional context
Add any other context or screenshots about the feature request here.

recreated on edge, except for schema names in the mapper fields- here the schema name is the header

Could be worth discussing if the current way is the most logical, and/or if adding a preference is best.

[maxpatiiuk]

In 7.9.3.1 we see seemingly random additions of table names in query outputs. In the screenshots below, one of the locality fields shows as locality.datum, the other ones only have the field name. Ditto with the Geo Coord Details and CO.

The logic the code follows right now is:

1. if the field label is 2+ words, then assume it's unique enough to identify what this field is about without the need for a table name before it
2. if the field label is just 1 word, then it's unlikely to be specific enough to describe clearly what table it's from, so table name is added explicitly

Is this something that could be made a user preference? Otherwise it would be more consistent to just add the table name to every field (though I suspect that will also not be the preferred option for many people as it will clutter things up).

Yes, we could add a pref for making this more explicit - though, that would make table headers much longer, thus potentially making it harder to read the query results

I can see how this may be helpful if a query has say multiple instances of a Notes/Remarks field

That could work too, though would be a bit more complex, as at the moment, the algorithm that converts "arbitrary mapping path to a shortest descriptive label possible" is considering each path in isolation, not cumulative

but the examples above are short queries where there is no 'multiples' of the fields within the query itself. Also, the second example shows the catalognumber field with the table name - I can't see more than one field with that name in the schema?

The algorithm at the moment only counts spaces, not / - we could improve that.

Also, we maintain a list of fields that are descriptive on their own, without a need for a table name. Catalog Number should definitely be added to that list

specify7/specifyweb/frontend/js_src/lib/components/WbPlanView/mappingPreview.ts

Lines 52 to 59 in aa434e5

	const nonGenericFields = new Set<string>([
	'latitude1',
	'longitude1',
	'latitude2',
	'longitude2',
	'action',
	'fields',
	]);

@grantfitzsimmons could you have someone look though the schema to find all such self-descriptive fields? or should we just assume that any field that has uniqueness constraint is self-descriptive enough?

[grantfitzsimmons]

should we just assume that any field that has uniqueness constraint is self-descriptive enough?

I believe this makes the most sense to me.

[CorinnaPaeper]

Hi @bronwyncombs - that all looks good. Thank you.