Add a cot formatter filter #6254
Conversation
There was a problem hiding this comment.
Nice implementation! This does resolve #6253!
Although, I am a little hesitant in always enforcing the filter on the backend.
This change might make it difficult for users to arbitrarily search for Collection Objects which have similar, but different CollectionObjectType catalogNumber formatters.
For example, consider there are two formats, one of NNNN#####, and one ######### where N is a non-incrementing digit and # is an incrementing digit- each of which are invalid against the collection default format, AAA-##### where A is any letter.
With this setup, there is no way for a user to search across all of their "numeric" CollectionObjects without adding a duplicate filter for each numeric formatter, as demonstrated in the below video:
Screen.Recording.2025-02-23.at.11.58.16.PM.mov
This exact setup is probably pretty unlikely, but how likely is the generalization of the problem?
Will users want or expect to generically search across CollectionObjects using catalogNumber without the results being restricted to which field format(s) they used for catalogNumber?
If this is the case, it is somewhat contradictory to the Issue mentioned in #6253 (comment), but I think the problem mentioned above (being too restrictive when filtering) could potentially be just as detrimental as the ones pointed out in #6253 (comment) (being too open when filtering).
If this would be a problem with users, would something like the following solution be sufficient to solve both Issues?
Instead of restricting the results in the backend based on the format name of the catalogNumber filter(s), maybe we could instead add a CollectionObjectType -> Name filter to the query on the frontend whenever the user explicitly chooses a catalogNumber format via the ⚙️ button.
So if the user wants to search on CollectionObjects using the Numeric and ByYear COT catalogNumber formats, we add a COT -> Name -> In filter for each format they select using the ⚙️ button.
That way, we're very clear in letting the user know that the results will be restricted to COs with those COTs, and they still have the option to modify the filter before running the query; so the restriction in filtering by COTs based on the format(s) they're using is still the default, but entirely configurable.
|
I agree with your suggestion to add a In my view, Jason's approach not only gives users the flexibility they need but also keeps the search process largely intuitive and user-friendly. We just need to make sure our users can easily find what they’re looking for, and Jason's solution seems like a great way to achieve that. |
Triggered by aba0971 on branch refs/heads/issue-6253
|
The main "core" of this feature is implemented! qb_auto_cot_filter.movSome notes/documentation on the current behavior of the feature:
@specify/ux-testing @specify/dev-testing If I'm understanding correctly, the initial problem was that it wasn't initially clear what the "Select Formatter" option next to CatalogNumber was doing or supposed to do. More specifically, it could be taken that selecting a format for CatalogNumber would alter the results of the Query, which is not the case. If this extension could be more confusing and/or frustrating to work with, it might just be better to not include it in the first place. What do you guys think? |
Triggered by b34b627 on branch refs/heads/issue-6253
Previously if a QueryField was added, the last QueryField would be scrolled to, regardless of where the new QueryField(s) are inserted
|
After some discussion I am also uncertain if this would be intuitive to users and I agree with @grantfitzsimmons in that I don't like that we're adding a filter to the query just because they select a format. I think this might be more confusing especially since we added the Here is the original problem in production: 04-03_10.29.mp4 |
|
During the development meeting on April 30, 2025, we discussed the lack of consensus on the usefulness of this PR. We are open to reintroducing these changes if our members demonstrate a need for them. |
EDITED by @melton-jason: Updated PR Description and added Testing Instructions
Fixes #6253
Old PR Description
Adds a filter for including only COs that use the selected COT formatter.
NOTE: This means the results are filtered by formatter name rather than COT name.
If a COT formatter matches the collection's default catalog number formatter, the results will include those COs as well even if they belong to a different COT with no specified
catalogNumberFormatNameThis PR makes it so that when a CatalogNumber format is selected in the QueryBuilder, if there are no other filters to the CollectionObject's CollectionObjectType, it adds a
Type -> Namefilter to the Query below the CatalogNumber query fieldcot_type_to_query.mov
Checklist
self-explanatory (or properly documented)
Testing instructions
Testing instructions coming soon