Skip to main content

​
Extensions

Pawtograder provides four mechanisms for letting a student submit past the original due date: student-spent late tokens, instructor-granted manual extensions on a single assignment, instructor-granted student-wide extensions that cover a student across the course’s assignments, and instructor-gifted tokens. Manual extensions are usually granted from the assignment’s Manage Due Date Exceptions page; student-wide extensions and gifted tokens are granted at the course level, from Course Settings → Due Date Extensions (instructors only). For the per-assignment token cap, see Configuration → Late tokens.
Tell your students what you chose. Late tokens are off until you turn them on, and an extension exists only where you grant one, so the policy on this page is yours to set. Pawtograder shows a student the deadline they have, not the reasoning behind it — if your course grants late tokens, requires them to be claimed before the deadline, or gives extensions on request, say so in your own course materials. What students read is Late Tokens and Extensions.

​
Late tokens

Late tokens are off by default at the platform level. Both the per-assignment maximum and the class-wide allotment start at zero, so a student can only spend a token once you have raised both above zero. Granting late tokens is a course policy choice, not a default you inherit. When the assignment allows late tokens, each enrolled student can spend one token per 24 hours of extension on their own due date.
  • Whether a token must be claimed before the deadline depends on Require students to apply late tokens before the original due date on the assignment. When that box is unchecked, a late token is applied automatically when a student submits after the deadline.
  • Every spent token is recorded as a due-date exception and appears in the Extension History table on Manage Due Date Exceptions.
  • Students see “You have N late tokens remaining” in the due-date widget on the assignment page.

​
Late tokens on group assignments

A group extension records one due-date exception, against the group, and it moves the deadline once for the whole group. But the token cost is not shared: every member of the group is charged a token. Every balance calculation attributes a group exception to all of that group’s members, and the instructor roster view fans the charge out the same way. The in-product dialog says so too — “all group members will have a token deducted.” The corollary is that only the acting student’s balance is checked. A teammate with zero tokens left does not block the group, and will simply go further into deficit against the class allowance. The student-facing Late Tokens and Extensions page describes the same behavior; if you expected group extensions to cost one token total, budget your Late Tokens Per Student allotment accordingly.

​
Granting a manual extension

From Manage Due Date Exceptions, click Adjust Due Date on the student’s (or group’s) row. The dialog accepts either:
  • A Target Due Date (date picker) — choose the new deadline directly.
  • Hours Extended and Minutes Extended — extend by a duration rather than choosing an end time.
Use Tokens to Consume if you want the extension to be billed against the student’s late-token balance, or leave it at 0 for a free extension. Confirm with Add Due Date Exception.
The Notes field is not private. Its helper text reads “Visible to the student and the staff”, and students can indeed read the notes on their own due-date exceptions. Write only what you would say to the student directly.
For group assignments, the exception applies to every member of the group automatically. You can also add a single-assignment exception without leaving the course level: Course Settings → Due Date Extensions → Assignment Exceptions has an Add Exception button whose dialog asks for the Assignment and the Student alongside Hours, Minutes, Tokens Consumed, and a Note. Same result, one screen for the whole course, which is convenient when you are entering several exceptions on different assignments at once.

​
Granting a student-wide extension

A student-wide extension is the blanket accommodation: one entry that extends that student’s deadlines across the course rather than on one assignment. Go to Course Settings → Due Date Extensions → Student Extensions (instructors only) and click Add Extension on the Student-Wide Extensions table. The Add Student-Wide Extension dialog asks for:
  • A Student.
  • Hours — the length of the extension, prefilled with 24.
  • Include lab assignments — tick this if the extension should also cover assignments whose deadline is tied to the student’s lab section. Left unticked, those assignments keep their lab-based deadline.
Confirm with Add Extension. The table then lists the student, the hours, whether labs are included, and when the entry was created and last updated, with buttons to edit or delete it. Granting the extension writes a due-date exception of that length onto each eligible individual assignment in the course that is not archived, and each eligible assignment you create afterward picks the extension up as it is created. Lab assignments are included only when you check Include lab assignments, and group assignments are left out (see the note below). The exceptions cost no tokens, and the student sees each one on the assignment page as a normal extension.
Editing or deleting a student-wide extension changes what future assignments get; it does not rewrite the exceptions already on the student’s existing assignments. The product says so when you save: “updates do not retroactively modify existing exceptions.” To change a deadline that has already moved, edit that assignment’s exception on its Manage Due Date Exceptions page.
The dialog is explicit that a student-wide extension covers the course’s individual assignments and that group assignments are not affected. When a student with a blanket accommodation also has a group assignment, grant that assignment its own exception from Manage Due Date Exceptions — that moves the deadline for the whole group.
Because each one lands as an ordinary due-date exception, everything under Self-review deadlines and extensions applies to student-wide extensions too. The student-facing description is on Late Tokens and Extensions.

​
Gifting late tokens

Gifting is not on the assignment page. Go to Course Settings → Due Date Extensions → Assignment Exceptions (instructors only), then click Gift Tokens and fill in the Gift Late Tokens dialog: an Assignment, a Student, Tokens to gift, and a Note prefilled with “Tokens gifted by instructor”. Gifted tokens are added to the student’s available balance and are spendable like any other token. Use this to compensate for special circumstances (illness, accommodation, transit issues) without picking a specific new deadline. The gift stacks on top of the class-wide Late Tokens Per Student allotment.
Gifting is instructor-only. A grader who tries it is refused with “Unauthorized: Only instructors can gift tokens”, so graders cannot gift even though they can see the Due Date Extensions tables.
A gift is recorded as a due-date exception that returns tokens instead of spending them, with zero hours and zero minutes, so it raises the student’s allotment without moving any deadline. That is why gifts show up in the same exception tables as extensions.

​
Self-review deadlines and extensions

A self-review normally follows the student’s final due date. When Release self-evaluation at is blank, Pawtograder creates the review once that final due date has passed and sets its deadline to the final due date plus the self-evaluation’s Hours due after this assignment offset. The final due date already includes the student’s late tokens and manual extensions, so an extension granted before the review exists carries its deadline with it. No manual action is required. An extension granted after the self-review already exists also moves it: granting the exception shifts that student’s review assignments for the assignment by the same interval. Note it shifts them whether or not the review has already been completed.
The two ways a self-review deadline moves do not behave the same way, and it is worth knowing which one you are using.
  • Granting a due-date exception (a late token, a manual extension) shifts the student’s review assignments even if the review is already complete, and regardless of review round — so it moves that student’s grading-round review assignments for the assignment too, not only the self-review.
  • Editing the assignment’s own due date shifts only self-review review assignments, and only ones that are not yet completed.

​
Assignments with an explicit self-review release time

Setting Release self-evaluation at changes the review’s initial schedule. If the assignment is due at X, the explicit release time is Y, and Hours due after this assignment is K, the review is initially released at Y and due at Y + K. That initial calculation does not use the assignment’s due date or any per-student due-date exceptions. With early submission disabled, the review normally does not exist until Y. Changing the assignment’s due date from X to X + D before Y therefore leaves the initial self-review deadline at Y + K. A due-date exception granted before Y has the same result. To change that initial deadline, adjust Y or K before the review is created.
The explicit release remains Y even if an extension moves the assignment’s due date later than Y. In that case the self-review can be released before the extended assignment deadline.
Once the review assignment exists, Y does not permanently pin its stored deadline. Later changes use the same triggers described above:
  • A positive due-date exception shifts that student’s existing review assignments, regardless of review round or completion status.
  • Editing the assignment’s own due date shifts its existing incomplete self-review assignments by the same interval. For example, changing X to X + D after Y moves an incomplete self-review from Y + K to Y + K + D.
Changing K after a review assignment exists does not recalculate that row’s deadline. Use the bulk review due-date update to set existing rows to the intended absolute time.
An exception of zero or negative length does not shift anything. Only an extension that adds time moves an existing review deadline, so gifted tokens and corrective adjustments leave it where it is.
A self-review deadline moves when an extension is first granted, and each further extension moves it again by its own length. Editing or deleting an extension afterwards does not move it back: the shift that was already applied stays applied, while the student’s assignment deadline is recomputed from whatever extensions remain. So the moment anyone edits or deletes an exception, the two drift apart, and a review deadline can end up earlier or later than the extension history implies. If you have edited extensions on an assignment with self-reviews, reset the review deadlines in bulk rather than trying to reason the drift back by hand — see below.

​
Bulk review-due-date updates

The Grading Assignments page lets you adjust grading and self-review review due dates in bulk for a section, a rubric, or a set of selected rows. This is the way out of the drift described above: it sets review due dates to an absolute value rather than adding to whatever is there, one rubric per call, optionally limited to reviews that are not yet complete. See Bulk Actions for the procedure.