search

UCI-IN4MATX-191-Token-ATM / token-atm-spa

Single-Page Application (SPA) for Token ATM using Angular.
0 stars 0 forks source link

Creation and Mangagement of Canvas Assignment Overrides may not match Instructor's Expectation #122

Open epsilonError opened 2 months ago

epsilonError commented 2 months ago

On approval a student with existing individual-level override is not changed by Token ATM (works as described).

Note: This may be unexpected by instructors/students. Should we follow the same process that Canvas uses and take the latest of the Due/Until times between existing and configured individual level overrides?

Under current planned use, I believe this possible expectation is an edge case. But may become confusing in future. If the future "review" functionality includes double checking students' approved requests and the overrides on canvas, that could give insight into whether or not this is common and/or worth allowing instructor's to manually decide/fix from Token ATM.

The most important concern here is whether Token ATM should modify an existing individual-level override. Currently, there are two possible cases where an individual-level override eixsts:

  1. The override is created by Token ATM. This will happen if an error occurred during the last time the current request is processed. In this case, modifying the override is not an issue. However, it requires a better error detection and recovery logic.
  2. The override is manually created by the instructor. In this case, modifying the individual-level override could possibly breaks the instructor's expectation. But I agree that allowing the "review" functionality to detect and possibly "fix" such a situation could be helpful.

In addition, there is currently no way to differentiate the two cases mentioned above. The override creation and management logic needs to be changed to enable the differentiation.

Originally posted by @yongkanm in https://github.com/UCI-IN4MATX-191-Token-ATM/token-atm-spa/issues/78#issuecomment-1729966499

epsilonError commented 1 month ago

Proper handling of this most likely requires and out-of-band review/correction by instructors.

The review functionality could identify simple cases that allows transparent updating. Example: A manually added override that shares the same resulting date.

Confirming if all such dates should be deleted/updated would make the instructor's burden less.

This same review functionality could also be used to update a change in settings for the Token Option or the Assignment Dates. Basically a batch updating of all current individual overrides to match changes made after first requests.

epsilonError commented 1 month ago

For non-transparent changes, there are implications for the student's Token Balance.

Currently, the cost is always paid by the student even if a change isn't actually made.

And postponing token balance changes isn't supported. And arbitrary requests on a student's behalf is also not supported.

Flexibility in those 2 areas would be needed to actually support non-transparent changes. Though retroactive refunds could work around the absence of postponing a token balance change functionality.

yongkanm commented 1 month ago

For non-transparent changes, there are implications for the student's Token Balance.

Currently, the cost is always paid by the student even if a change isn't actually made.

And postponing token balance changes isn't supported. And arbitrary requests on a student's behalf is also not supported.

Flexibility in those 2 areas would be needed to actually support non-transparent changes. Though retroactive refunds could work around the absence of postponing a token balance change functionality.

I think allowing arbitrary requests to be made on a student's behalf is a more feasible option. Either postponing token balance change or supporting retroactive refunds might cause changes in process results for requests made later than the request concerned. This would require all token options to have cancellable side effects, constraining the possibilities of token options.

As this use case focuses on adjusting manually added overrides, instructor intervention is already inevitable. Therefore, it might be better to minimize the influence on the normal workflow while helping the instructor apply manual fixes. Allowing the instructor to act on the student's behalf makes it much easier for instructors to make adjustments without breaking Token ATM's expectations.