Is your feature request related to a problem? Please describe.
Currently in Specify 6 and 7 there is no ability in the query builder to search on any arbitrary field in the tree table once you select a specific rank.
Current Behavior
At (any rank)
See that all fields and relationships are exposed in the list of fields to choose from
The stringids are constructed as you'd expect:
1,9-determinations,4-preferredTaxon.taxon.fullName
At {Rank} level
Only author and fullName can be chosen from the list of fields once you select a level in the tree.
The stringids associated with these rank-specific query items are unusual. They are formatted as follows:
1,9-determinations,4-preferredTaxon.taxon.Kingdom
1,9-determinations,4-preferredTaxon.taxon.Kingdom Author
It looks like there is special logic handling these treeNodeCols when constructing a string ID for these items.
Describe the solution you'd like
Currently, users can only choose two fields at any given tree rank:
Users should be able to select any rank in a tree (e.g. Family, Genus, Species, etc.) and select any field in the tree table at that level.
Instead of seeing only these two fields:

You should see this:

The list of fields should be comprehensive, including Author, Common Name, Full Name, GUID, Is Preferred, Name, Protected Status, Remarks, Source.
Reported By
Louisiana State University Museum of Natural Science, University of Washington, University of Florida, CSIRO, University of Kansas, many others
Initially reported in #2364
@grantfitzsimmons:
Currently in Specify 7 and 6 you are restricted to only seeing the taxon full name and author for each rank. This restriction causes issues when it comes to running a query from the collection object or creating reports and labels where you want to reference a specific field for a specific rank.
In this case, I am reworking the University of Washington's labels to reference the family number, stored in a text field at the family level.
There is no way to reference this number without using relationships through the "Parent Taxon" several times and hoping that the parent is the family. For their database, all specimen records are determined to species at the moment, but this is going to change in the future and the flexibility is necessary. I have to stack parent relationships to ensure that it will not be missed.
@maxpatiiuk said the following in this comment:
From what I remember Ben told me, this restriction was put in place artificially just to match the limitations of specify 6 (yeah, this is from the dark dark days where sp7 was limited just to not outcompete specify 6)
Here is the code for that:
|
TAXON_FIELD_RE = re.compile(r'(.*) ((Author)|(GroupNumber))$') |
|
|
|
# Look to see if we are dealing with a tree node ID. |
|
TREE_ID_FIELD_RE = re.compile(r'(.*) (ID)$') |
(it currently allows only Author, ID and Group Number fields - and full name implicitly if field name was not provided). Modifying that code and lifting the restriction on the front-end should fix this
Last march I asked for that code to be removed but no forward movement has occurred since that discussion.
Issues to Resolve:
Is your feature request related to a problem? Please describe.
Currently in Specify 6 and 7 there is no ability in the query builder to search on any arbitrary field in the tree table once you select a specific rank.
Current Behavior
At (any rank)
See that all fields and relationships are exposed in the list of fields to choose from
The
stringids are constructed as you'd expect:At {Rank} level
Only
authorandfullNamecan be chosen from the list of fields once you select a level in the tree.The
stringids associated with these rank-specific query items are unusual. They are formatted as follows:It looks like there is special logic handling these
treeNodeColswhen constructing a string ID for these items.Describe the solution you'd like
Currently, users can only choose two fields at any given tree rank:
Users should be able to select any rank in a tree (e.g. Family, Genus, Species, etc.) and select any field in the tree table at that level.
Instead of seeing only these two fields:

You should see this:

The list of fields should be comprehensive, including
Author,Common Name,Full Name,GUID,Is Preferred,Name,Protected Status,Remarks,Source.Reported By
Louisiana State University Museum of Natural Science, University of Washington, University of Florida, CSIRO, University of Kansas, many others
Initially reported in #2364
@grantfitzsimmons:
@maxpatiiuk said the following in this comment:
Last march I asked for that code to be removed but no forward movement has occurred since that discussion.
Issues to Resolve: