-
Notifications
You must be signed in to change notification settings - Fork 4
mrc-357 add autocomplete and validate selected users #106
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
Conversation
Codecov Report
@@ Coverage Diff @@
## master #106 +/- ##
============================================
+ Coverage 95.03% 95.07% +0.04%
- Complexity 518 519 +1
============================================
Files 141 141
Lines 2455 2479 +24
Branches 184 185 +1
============================================
+ Hits 2333 2357 +24
Misses 77 77
Partials 45 45
Continue to review full report at Codecov.
|
| .transform() | ||
| .secure(usersManage) | ||
| .secure(usersManage), | ||
| WebEndpoint("/users/", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should this be /users/ or something more specific, like /emails/? It's just for returning valid user emails for the autocomplete...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If it's just returning emails I'd probably expect a more specific route, since we already have endpoint which are returning user models, which in a RESTful way I'd expect to be the resource I'd find at /users/. But since this isn't a part of the REST API and is just for the web app's internal use I guess it isn't so important!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actually, having said that, maybe we don't have anything returning the User model just now, as there's now a ReportReaderViewModel instead. Although maybe that will change once we've done the Admin screens.
I still think /users/emails might be a bit clearer!
EmmaLRussell
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, that bootstrap-typeahead is nice, makes life a lot easier!
It might be nice if, after you've added a new user, it cleared the email control, so you could just click back in there and start typing to get more auto complete results, rather than having to clear the box first.
Ooh actually, having said that, I've just noticed that you do get a little blue cross (that's come from bootstrap-typeahead I guess) which makes that easy to do anyway.
| .transform() | ||
| .secure(usersManage) | ||
| .secure(usersManage), | ||
| WebEndpoint("/users/", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If it's just returning emails I'd probably expect a more specific route, since we already have endpoint which are returning user models, which in a RESTful way I'd expect to be the resource I'd find at /users/. But since this isn't a part of the REST API and is just for the web app's internal use I guess it isn't so important!
| .transform() | ||
| .secure(usersManage) | ||
| .secure(usersManage), | ||
| WebEndpoint("/users/", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actually, having said that, maybe we don't have anything returning the User model just now, as there's now a ReportReaderViewModel instead. Although maybe that will change once we've done the Admin screens.
I still think /users/emails might be a bit clearer!
|
|
||
| fun getUserEmails(): List<String> | ||
| { | ||
| return userRepo.getUserEmails() |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So we're assuming that we always have a manageable number of users to be able to return the full list on each call? No value in doing an initial filter with first few letters here? Probably not for the number we have in Montagu, would just make the UI less responsive.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think so, yeah. The number of users would have to be pretty high for this to be a problem.
| } | ||
|
|
||
| @Test | ||
| fun `gets user emails in alphabetical order`() |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is this test name misleading? I can't see ordering code, and I didn't think containsExactlyElementsOf checked order.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
containsExactlyElementsOf is order sensitive. Seems sqlite returns the records in alphabetical order, hence no extra ordering logic.
|
Ok, |
EmmaLRussell
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The first commit commit implies that the intention was to clear the email field after successful add, but it doesn't seem to. Not sure if I'm missing something!
|
Huh, ok, what I thought was the fix is this typo fixed here: (slightly confusingly I also fixed the naming convention from camel case to snake case at the same time) But it seems like resetting the |
|
Oh man, actually looks like that repo is dead. Last commit in October and lots of outstanding PRs. Maybe we should fork it and fix it. |
Contains commits from #105 so merge that one firstFound a nifty bootstrap typeahead vue component for this.