Instructors and TAs need a way to test an assignment before releasing it to students
Nobody has claimed this yet.
Assessment
- Difficulty
- 5/5
- Estimated time
- Over a week
- Newbie friendliness
- 35/100
Research direction
Start by reading code_editor.py's run_code and _verify_student, then compare submission.py's upload_submission behavior. Decide how staff testing should work for upload-only assignments, and inspect reviewGrades and manageSubmissions for roster handling. Done means staff can test before release without test data appearing as student submissions or affecting grades and counts.
Written by the indexing model from the issue text.
Description
Currently, both the code editor (run_code/submit_code in code_editor.py) and file-upload submission (upload_submission in submission.py) block non-student callers — _verify_student has no staff bypass, and upload_submission has an explicit comment: "Instructors/TAs should not upload submissions on behalf of students." There's no way for staff to verify an assignment's autograder works before publishing it to students.
run_code is already ephemeral (no Submission row is written — "Run code without creating a submission" per its own docstring), which makes it the natural place to allow staff through for code-editor assignments. Two things stand in the way even there:
_verify_studentincode_editor.pyhas no staff bypass.run_codeexplicitly rejects unpublished assignments (if not assignment.published: raise BadRequestError(...)) — but testing before publishing is the entire point of this request, so that gate needs a staff exception too.
Upload-only assignments (enable_code_editor=False) have no ephemeral equivalent — upload_submission always persists a Submission row, and there's currently no flag on Submission to distinguish a staff test run from a real one. Supporting staff testing there means either adding a Submission flag (schema migration) or a separate non-persisted "dry run" execution path, and either way, reviewGrades/manageSubmissions' rosters and any grade-count/dashboard logic would need to exclude staff test data — which they don't do today for any role (see the linked roster-filtering issue).
Reported by Cecilia (yczhangcc) during review of PR #355.
- Dominant language
- Python
- Stars
- 13
- Forks
- 0
- Avg merge
- 2h 4m
- Merged PRs (30d)
- 1
Getting set up
- Ships a Dockerfile or Docker Compose file
- No pull request template
- No contributing guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from kiat/codeAssist
-
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
kiat/codeAssist#391 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
kiat/codeAssist#364 · 1 comment ·
-
Difficulty 3/5 1-2 days Newbie friendliness 63/100
kiat/codeAssist#392 ·
-
Difficulty 4/5 3-5 days Newbie friendliness 52/100
kiat/codeAssist#390 ·
-
Difficulty 4/5 3-5 days Newbie friendliness 42/100
kiat/codeAssist#389 ·
Similar issues
-
SSM GetParameter throttling during concurrent workflow launchesPossibly taken @alexiswl claimed this today. Open
Difficulty 2/5 1-3 hours Newbie friendliness 80/100
-
[Bug] Dev image build fails: `npm install` in the root Dockerfile runs out of memory (exit 134)Possibly taken @andest01 claimed this today. Open
Difficulty 2/5 1-3 hours Newbie friendliness 75/100
Maintainers usually reply within 1 day
-
enhancement good first issue
Difficulty 2/5 1-3 hours Newbie friendliness 79/100
pesu-dev/discord_bot#97 ·
-
Difficulty 1/5 1-3 hours Newbie friendliness 88/100
gradio-app/gradio#13964 ·
Maintainers usually reply within 1 day
-
Difficulty 1/5 Under an hour Newbie friendliness 93/100
BSData/horus-heresy-3rd-edition#3232 · 1 comment ·
Maintainers usually reply within 1 day