-
Notifications
You must be signed in to change notification settings - Fork 302
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
Autocomplete usernames when inviting students and teachers #6032
base: main
Are you sure you want to change the base?
Conversation
This is how we are going so far, still a bit of work to be done, but the search is already there 2024-12-09.20-18-46.mp4 |
website/database.py
Outdated
@@ -109,7 +109,8 @@ def __init__(self): | |||
}), | |||
indexes=[ | |||
dynamo.Index('email'), | |||
dynamo.Index('epoch', sort_key='created') | |||
dynamo.Index('epoch', sort_key='created'), | |||
dynamo.Index('username', sort_key='epoch', keys_only=True) |
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.
No please.
dynamo.Index('username', sort_key='epoch', keys_only=True) | |
dynamo.Index('epoch', sort_key='username', keys_only=True) |
Also, putting a Condition on a PK doesn't make sense. A partition must always be matched with full key equality. If the DynamoDB layer allowed you to formulate the query below, something is wrong
EDIT: There was a bug that would only manifest for tables with only a partition key and not a sort key. In that case, the protection that should give you an error when trying to put a condition onto the PK wouldn't work. I fixed it in the linked PR.
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.
Oh I see, the abstraction layer complains if you use the same partition key multiple times so you were forced to reverse the keys to get it to do anything at all.
That restriction is not strictly necessary. It's not enforced by Dynamo, but by our abstraction layer for the convenience of identifying which index to query. Let me see what I can do about that.
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.
Here is a PR you will need to merge before you can set up the indexes the way you need them: #6034. Unfortunately, this will also require you to annotate all existing epoch queries to indicate what index to use. I know at least one of them in the admin interface, and there aren't any tests on those, so do have a good look around.
The motivation for the design decisions is in the linked PR.
(BTW I created the necessary (epoch, username)
indexes in the actual DDB tables already, so you don't need to do anything there anymore)
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.
Oh I see, the abstraction layer complains if you use the same partition key multiple times so you were forced to reverse the keys to get it to do anything at all.
That restriction is not strictly necessary. It's not enforced by Dynamo, but by our abstraction layer for the convenience of identifying which index to query. Let me see what I can do about that.
Yes, so I thought I was making a mistake. Thanks for pointing it out and fixing it.
(BTW I created the necessary (epoch, username) indexes in the actual DDB tables already, so you don't need to do anything there anymore)
Neat!
app.py
Outdated
@app.route('/search_students', methods=['GET']) | ||
def filter_usernames(): | ||
search = request.args.get('search', '') | ||
results = DATABASE.get_users_that_starts_with(search) |
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.
Probably you want to only do an actual search once you've gotten at least one character.
Otherwise the first query will always return the same first 10 items from the users table ["000_test", "4242 i like kittens", "aaron a. aaronson", ...]
. Not useful, and people will get tired of it.
Just return an empty list otherwise.
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.
Oh for sure! I was thinking about that yesterday, I'm only going to look data if I there's more than one character.
I have to deal with the conflicts, but this is done :) Sorry it took so long! |
Fixed the tests, but still gotta update the ones for the invites. |
…to search_usernames
…to search_usernames
…to search_usernames
…to search_usernames
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.
When I try to invite students and I fill in a username which just yields to search results, I get a message "There are no students in this class". But this is not true - I have a person in my class. Not sure what this message means? That no invites will be sent via this dialogue?
@@ -161,6 +162,31 @@ class Modal { | |||
}); | |||
} | |||
|
|||
public search(message: string, confirmCb: (...args: any[]) => void, declineCb: () => void = function(){}, args: any[]) { | |||
console.log(message, confirmCb, declineCb) |
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 console.log() is probably not intentional
@@ -9,6 +9,7 @@ import { autoSave } from './autosave'; | |||
import { HedySelect } from './custom-elements'; | |||
import { Chart } from 'chart.js'; | |||
import { setLoadingVisibility } from './loading'; | |||
// import { postJson } from './comm'; |
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.
probably we can get rid of this?
@@ -0,0 +1,12 @@ | |||
{% if usernames|length == 0 %} |
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.
Definitely something minor: the rest of the files have names separated with dashes but this one uses underscores. Is this intentional?
usernames = sorted(usernames) | ||
return render_template('modal/htmx_search_results_list.html', usernames=usernames) | ||
|
||
@route("/invite", methods=["POST"]) | ||
@requires_teacher | ||
def invite_student(self, user): |
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.
Now that this endpoint is called /invite
and used for both student and teachers, perhaps we should change the name too
self.db.add_class_invite(data) | ||
|
||
invites = [] | ||
for invite in self.db.get_class_invitations(Class["id"]): |
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.
This exact snippet appears also in for-teachers.py. Do you think we can make it reusable?
self.item = item | ||
|
||
def to_dynamo_expression(self, field_name): | ||
return f"not (contains(#{field_name}, :{field_name}_prefix))" |
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 find the _prefix
suffix confusing. It makes sense in the BeginsWith condition but why is it here?
I like it that the invited accounts appears as a block with a cross to delete them from the invitation list. Although I was afraid that the invitations would be send right away when I click 'invite', maybe we can change 'invite' to 'add' and 'ok' to 'invite'? When I invite a teacher and the suggestion list is empty I also get the message “there are no students in this class” . If invitation is already send, but not accepted, the username still appears in the list as if the invitation was not send. This might be confusing, especially in the current UI where the invitations are out of sight at the bottom. Can we maybe change the 'invite button' to a disabled button with 'already invited' or something similar in these cases? Or don't show them in the list? I noticed that the username Teacher3 for example starts with a capital if you check the profile name at the top right, but the search only finds them if you use a small letter. Can the search be indifferent for capitals?
If a student is in another class it doesn’t show up in the list. I think this is good behavior since students can’t be in two classes at the same time. @MarleenGilsing we should be clear about this in the teacher manual.
|
Adds autocomplete functionality for searching usernames when adding a student or a second teacher.
It does so by matching the usernames in the database with the user's query, so if search for: user, it'll show me: user1, user2, user3, etc.
In the process of doing this I wanted to use a bit more of the power of Dynamo, instead of relying on filtering the data trhough python. To this end I added 2 extra Dynamo conditions: one for checking if a set exits, and another for checking if an element is not in a container.
I also updated HTMX and Tailwind, but maybe I can update those in a different PR?
I tried to improve the code a little bit also by avoiding duplication where I could, so instead of having 2 function for adding teachers and students I merged them together since they were mostly the same.
Fixes #4689
How to test