Allow simultaneous creation of multiple extensions

[damianhxy]

Description

• Update autocomplete on manage extensions page to support multiple students at once
• Update backend logic to support creating / updating multiple extensions at once

Motivation and Context

Currently, extensions can only be created or updated for one student at a time. This is tedious if multiple students should be given the same extension, as surfaced during 213 user testing.

Resolves #1854

How Has This Been Tested?

Creating extensions

e.g. give 1 day extensions to 3 users (user0, user1, user2)
note: already selected users are filtered from the dropdown, to prevent users from selecting them again

Updating extensions

e.g. give infinite extensions to 3 users (user2, user3, user4) -> this updates user2's extension

Autofill

• Clicking on student email(s) automatically adds them to the list of selected students. A warning message is displayed if the student was already added (e.g. clicking or manual input)
• If selected student(s) all have the same extension, the details will be autofilled. Otherwise, it displays default values

XSS

• Create users with html tags in their names, ensure that the names are correctly escaped in the dropdown
  

Error conditions

• Click create without any users selected -> "No users were specified!" error message
• After selecting several students, modify the value of #course_user_data to include invalid cuds -> "No user with id xxx" was found for this course
• Attempt to give extension of -1 days (after disabling min check) -> "Validation failed: Please enter (≥ 0) days of extension, or mark as infinite."

Ensure that when an error occurs, no changes are applied

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)

Checklist:

• I have run rubocop for style check. If you haven't, run overcommit --install && overcommit --sign to use pre-commit hook for linting
• My change requires a change to the documentation, which is located at Autolab Docs
• I have updated the documentation accordingly, included in this PR

[lykimchee]

Testing:

• Creating extension for multiple users
• Autofill if all selected users have the same extension (from original task)
• Autofill clears if all selected users have different extensions
• Able to update extensions (for multiple users as well) (from original task)
• Warning popup for already added users
• No users specified error flash

The dropdown is super clean I love it!!! It looks like this task ended up being a lot more complicated and bigger than I initially thought, especially with you adding the security and input validation checks, tysm Damian!!

I had a couple questions that don't necessarily require changes, but:

• I remember we had some discussion during one of the team meetings about a specific date format, are we updating the "Select a new due date" to be that format? (I don't remember what we ended up deciding for the finalized date format though, so let me know!)

• Apologies for noticing just now and not when actually doing design overviews, but all three dates (including from the previous screenshot) on this page are a different format— do we want to do anything about this?

• Would you prefer having this merged to master or to feature/new-manage-submissions?

That's it for questions! This is beautiful I love the dropdown so much :'))

[damianhxy]

I remember we had some discussion during one of the team meetings about a specific date format, are we updating the "Select a new due date" to be that format? (I don't remember what we ended up deciding for the finalized date format though, so let me know!)
Apologies for noticing just now and not when actually doing design overviews, but all three dates (including from the previous screenshot) on this page are a different format— do we want to do anything about this?

In #1895, Michelle decided on a format, I believe in discussion with Victor. However, given that extensions are on a day-by-day basis, I feel that such precision is not required. I will standardize the formats to something like MMM D YYYY (e.g. Mar 11 2023). This is slightly different in that it uses a 4 digit year, but it feels more readable to me.

Would you prefer having this merged to master or to feature/new-manage-submissions?

I think this is a fairly standalone feature that can be merged to master, so that 213 can make use of it (unless new manage submissions will be merged to master soon?)

[damianhxy]

@lykimchee New standardized date format (PR description has also been updated). Let me know what you think of this, as well as merging into master!

[lykimchee]

Merging into master sounds good to me!

I think the new date format looks good as well! I would prefer to keep the specific time for just the original due date though, in the format of Michelle's PR (except I like your year format better).

With this change, the MM-DD-YY part of the dates would still be consistent, even though the original due date would have an additional timestamp, so I don't think it would be confusing to look at— but let me know your thoughts though!

[damianhxy]

Sounds good, I've made the change!