Allow for exact matching on user search
mmulich opened this issue · comments
This comes out of openstax/cnx-publishing#83. We identify the users by username (partly because they are human readable and partly because that's what legacy uses.) As part of publishing, we make a shadow record of user-info in accounts (for search and representation of data). To do this, we search accounts by username (the only piece of unique data we have available at this time). However, it is currently possible to match a username within another username. For example, searching for username 'moo' would match 'moo', 'smoo', 'wolfsmoon', etc. We currently work around this by iterating through the results to exactly match the username.
We would like to possibly submit a new parameter that makes the search criteria match exactly. For example, searching for ?q=first_name:"Smoo Ooms"&exact=1 should match only records with that exact name. If this general case parameter exact=<boolean> can not be done, we at the very least would like something that can do an exact match on the username (maybe something like exact-username:<string>.
@Dantemss can you comment on this, and then maybe @nathanstitt can give it a shot?
Either way should be doable, JP. Just depends on your preference. exact-username would be a new block for KeywordSearch, while the exact=(boolean) param would have to be passed to the blocks.
Oh and actually I believe CNX wants to use the application_user search (not the user search).
User search searches all users, but is limited to (10 or 20, I forgot) results. If more than that would be returned, you get nothing.
ApplicationUser search can search any number of users that have been associated with CNX.
Maybe what we REALLY want is to implement the GET /application_user endpoint (commented out in the application_users_controller) and make it take a username instead of id (or either username or id).
I should probably mention that the use case here isn't using the application_user search. We are using the global search (/api/users.json), because the user isn't a member of this application. Publishing uses a different set of api keys than authoring.
Hm... sounds like it would be better to make users members of both apps, so you don't have the limitations of the global user search.
@Dantemss I'm sure it would be better to use the application_user search, but the most (if not all) CNX users will never sign into the publishing application. Therefore, if I understand correctly, they won't be registered as an application user, which means they won't show up in the search. Correct?
I think #75 is meant to allow different cnx apps to use the same app id and secret? That way publishing will be able to use the application user search.
Actually publishing doesn't even require the callback url etc, why doesn't it just use the authoring app id and secret?
Ah maybe Karen is right and all you need is multiple callback URL's?
Something seems fundamentally flawed to me about giving user info to an app they were never asked to sign up for. If publishing and authoring are the same app, they should use the same API key.
You can use the /api/users.json endpoint, just be aware that you will get no results for "moo" if someone (anyone) creates the moo1, moo2, moo3... moo50 (however many it is) users.
I think we should view authoring and publishing as distinctly different apps. Publishing will have a callback now that people will be logging into the application directly (currently using a second api key to do this on our staged instances). To clarify, the people logging into publishing are not the same people logging into authoring.
I would personally prefer the apps have separate api keys. But I can't justify a good reason at this time. So, I'll leave you to decide whether you want to do multiple callbacks or exact global search. (Also, I'll talk this over with @reedstrm to get his take on the situation.)
I talked this over with Ross. We will use the single key set. We will change to using the application_user search in publishing. The exact match is now a nice to have and would be very helpful. The need for multiple callbacks will be required.
Thanks!
@Dantemss can you leave some rough instructions for @nathanstitt to implement exact username matching, and then also break out a different issue for multiple callbacks?
@Dantemss Is the exact username search still going to occur in app/routines/search_users.rb ? If so, I think I've got it implemented now, with some specs to test that it works properly. I'm unclear on where it should be hooked up to though.
The work is in the exact-user-search branch: https://github.com/openstax/accounts/blob/0d4c1779a1707df297719e4563568f72a30a7285/app/routines/search_users.rb
Out of principle I don't think it should happen in the generic search API, but I suppose that is a reasonable temporary solution.
Reading comments above, it seems the exact match is no longer needed. What we do need is to change the oauth code to allow different callback url's for the same app.
@pumazi how urgent is the need to handle multiple callbacks?
@jpslav I think we can make due with a second set of keys at the moment. I'll not change the current code that uses the global_search until you have the multiple callbacks implemented (and therefore access to the application users). If we actually run into errors with the 10>results limit in global_search on a regular basis, I'm sure Ed will let you know. Otherwise, I don't think a great rush is needed. If you can have this in within a week or two, that would be great. Thank you.
From accounts view, cnx-publish and cnx-authoring are the same app, so should use the same codes (at least for now) In some sense, it's cnx-publishing's app, authoring just gets special access.
As to the 'one unique hit' exact-username would work. I can't see needing exact match on other arbitrary query components
In addition to doing multiple callbacks we're thinking of a /api/application_users/username/reedstrm endpoint to just jump directly to one user (instead of using the search mechanism).
On Feb 25, 2015, at 11:55 AM, Ross Reedstrom notifications@github.com wrote:
As to the 'one unique hit' exact-username would work. I can't see needing exact match on other arbitrary query components
—
Reply to this email directly or view it on GitHub.
@jpslav I've got a most specific answer regarding "when do you need this by." We are going to need the multiple callbacks before our release date (27-Mar-2015). Ideally, we'd like this functionality a week or so before that. I'm making do at the moment with some trickery, but that isn't transferable to production.
We are very close on it. @nathanstitt has a PR almost thru review.
On Mar 12, 2015, at 7:31 PM, Michael Mulich notifications@github.com wrote:
@jpslav I've got a most specific answer regarding "when do you need this by." We are going to need the multiple callbacks before our release date (27-Mar-2015). Ideally, we'd like this functionality a week or so before that. I'm making do at the moment with some trickery, but that isn't transferable to production.
—
Reply to this email directly or view it on GitHub.