Skip to content
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

Open
wants to merge 22 commits into
base: main
Choose a base branch
from

Conversation

jpelay
Copy link
Member

@jpelay jpelay commented Dec 10, 2024

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

  1. Log is as a teacher.
  2. Go to the class page
  3. Click on Add student and then on invite by username
  4. Search and check that a) no students that are already in the class show up.
  5. Select a few and send invitations. Check that they were sent
  6. Now click on Invite second teacher. Check that: a) only users that are teachers are shown, b) only teachers that aren't already second teacher's in the class show.
  7. Send invitations and see if they are added correctly.

@jpelay
Copy link
Member Author

jpelay commented Dec 10, 2024

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

@@ -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)
Copy link
Collaborator

@rix0rrr rix0rrr Dec 10, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No please.

Suggested change
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.

Copy link
Collaborator

@rix0rrr rix0rrr Dec 10, 2024

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.

Copy link
Collaborator

@rix0rrr rix0rrr Dec 10, 2024

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)

Copy link
Member Author

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)
Copy link
Collaborator

@rix0rrr rix0rrr Dec 10, 2024

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.

Copy link
Member Author

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.

@jpelay jpelay marked this pull request as ready for review February 6, 2025 05:58
@jpelay
Copy link
Member Author

jpelay commented Feb 6, 2025

I have to deal with the conflicts, but this is done :) Sorry it took so long!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Status: In Progress
Development

Successfully merging this pull request may close these issues.

💻 Autocomplete usernames
2 participants