-
Notifications
You must be signed in to change notification settings - Fork 52
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
Underscores are treated as wild cards (or something?) in record search form #1039
Comments
Not sure if we should "fix" this, or adjust the documentation. It's more of a poorly known feature than a bug. The "contains" and "starts with" are LIKE searches (aka wildcard). Both % and _ are wildcard characters, with % matching one-to-many characters and _ matching only one character, but you can use _ multiple times to represent an exact number of wild-characters. This can be a powerful search option. If you enter "_" or "%", it will search for just that character, rather than using it as a wildcard. "Fixing" this issue would involve appending a backslash to the beginning of these characters when they are in a search term, but that would remove the ability to add your own wildcards to a search term. |
Hotfix 2024-03-18 - Batch Georeferencer bug -- Fix for FATAL error when user has editor permissions for more than one collections, but not admin permissions - Occurrence Editor bugs -- Adjust occurrence editor to support filtering dynamic fields using 0 (zero) - resolves issue [#1038](#1038) -- Don't trim % off of search terms to allow for \% type search to match only on % - resolves issue [#1039](#1039) - Checklist Management -- Only sanitize output data once it is in the view. Fixes issue where cloning a checklist corrupts embedded html
In the editor-level record search form, searching by an underscore does not consistently look for the underscore character.
If you conduct this search ^ in this collection: https://cch2.org/portal/collections/misc/collprofiles.php?collid=12&emode=1, for example, you get over 84K records. I think it's looking for all records with a value in catalog number.
The text was updated successfully, but these errors were encountered: