Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add support for querying on any tree table field from a chosen rank #6011

Open
1 of 2 tasks
grantfitzsimmons opened this issue Dec 20, 2024 Discussed in #5935 · 0 comments
Open
1 of 2 tasks

Add support for querying on any tree table field from a chosen rank #6011

grantfitzsimmons opened this issue Dec 20, 2024 Discussed in #5935 · 0 comments
Labels
1 - Enhancement Improvements or extensions to existing behavior 2 - Queries Issues that are related to the query builder or queries in general 2 - Trees Issues that are related to the tree system and related functionalities.

Comments

@grantfitzsimmons
Copy link
Member

grantfitzsimmons commented Dec 20, 2024

Refer to #5935 for more details

Originally posted by grantfitzsimmons March 28, 2024
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

image

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.

image

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:

  • Author
  • Full Name

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:
image

You should see this:
image

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:

@grantfitzsimmons grantfitzsimmons added 2 - Trees Issues that are related to the tree system and related functionalities. 2 - Queries Issues that are related to the query builder or queries in general 1 - Enhancement Improvements or extensions to existing behavior labels Dec 20, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
1 - Enhancement Improvements or extensions to existing behavior 2 - Queries Issues that are related to the query builder or queries in general 2 - Trees Issues that are related to the tree system and related functionalities.
Projects
None yet
Development

No branches or pull requests

1 participant