Closed marc4-stanford closed 4 years ago
The search goes across all models, and all fields of the site, so if there are descriptions (or other) embedded within the metadata those results will be returned. The search is intended to be general like Google, so it just offers that single box and returns results. What you are hinting at is the need for some sort of more sophisticated algorithm, for user or admin, and I agree! However that kind of implementation is outside of the current scope, as it requires more than querying the database fields for the values and returning matches. I'm adding an enhancement to this request for some future work. I'd take a look at different backends such as elastic search in Django.
On the other hand, if you'd like to completely remove Plates, parts, organisms and tags from the search all together, this would be possible. @Koeng101 let me know if you'd like this done.
@Koeng101 how about I do a check for self.request.user, and in the case of admin or staff, I'll provide all models. Otherwise, I'll remove the ones specified above.
That sounds great. Another issue is that the the spelling/case/words make a difference.
A human knows that these are all the same but the search doesn't
@marc4-stanford that's your browser history / cache (called autocomplete), that's how it will auto populate fields that you've entered before.
Yes, I know. The question I have is that entering them into a search doesn't bring up the same results. But it should
I can try to handle the lower/uppercasing with this https://stackoverflow.com/questions/11743207/django-model-case-insensitive-query-filtering but the weird characters I'm not sure how to do without other parsing.
The question Hannah and I have been talking about this morning is whether we need to be more consistant on our naming conventions.
Ah interesting! So we definitely can handle the casing issue, I'm wondering about special characters however - there are most definitely special characters used throughout the site, so if you were to do a search for one (e.g., FG_JCVISYN3-distro-2
we wouldn't want to change that to the equivalent without them. However for tags there is a standard convention, they are made lowercase and spaces are replaced with dash (-). I'd definitely +1 using a more consistent structure so that you can parse the search query (removing special characters) without needing to worry that something is then hidden.
I have the lowercase/uppercase and adjustments to the search finished up locally, will push soon. I'm going to open another issue for the question about standard naming for that.
Search now ignores casing, and non staff and non admin users don't see plates, organisms, etc.
Closed with https://github.com/vsoch/freegenes/commit/8198f4747b05e14ab86a1dabdcdcbae35483b364 I'll be opening another issue promptly for discussion on naming.
Further discussion on naming conventions should go in https://github.com/vsoch/freegenes/issues/114 where I've also outlined how I'd go about it.
if you go to the home page search box or the search function and search for "openenzyme" you get results that are plates and tags.
Looking at it from an outsider, shouldn't it bring up the distributions first or only?
Plates, parts, organisms, tags don't really mean that much to outsiders since they can't get them.
Should there be a public search and an admin search?