You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently, mnvc provides a jobs feature, to allow for batch registration. Only courses remaining to be registered will be attempted on each iteration.
mnvc considers all 'registrable courses' to have been registered if no 'registration errors' occurred.
If a registration error, at the quick add/drop stage, only affects some courses, the entire batch will be considered a failure.
Using the require registrable courses option (-R), will prevent Minervac from attempting to register in courses when the process clearly won't succeed.
Even if this option is passed, Minerva could supply contradictory information leading to a quick add/drop error, causing the whole batch to fail.
Solution:
Minervac should check which courses have actually been registered for.
It could do this efficiently, by parsing the results of the quick add/drop request. This would however require parsing more Minerva GOOPML.
Another option would be to request a schedule and verify that the courses contained in it are what we expected. This would be more inefficient, but could reuse existing parsers. Perhaps it could be argued that this option is "safer" as it checks that everything seems normal about the user's registration in the course.
The text was updated successfully, but these errors were encountered:
Issue:
Currently, mnvc provides a jobs feature, to allow for batch registration. Only courses remaining to be registered will be attempted on each iteration.
mnvc considers all 'registrable courses' to have been registered if no 'registration errors' occurred.
If a registration error, at the quick add/drop stage, only affects some courses, the entire batch will be considered a failure.
Using the require registrable courses option (-R), will prevent Minervac from attempting to register in courses when the process clearly won't succeed.
Even if this option is passed, Minerva could supply contradictory information leading to a quick add/drop error, causing the whole batch to fail.
Solution:
Minervac should check which courses have actually been registered for.
It could do this efficiently, by parsing the results of the quick add/drop request. This would however require parsing more Minerva GOOPML.
Another option would be to request a schedule and verify that the courses contained in it are what we expected. This would be more inefficient, but could reuse existing parsers. Perhaps it could be argued that this option is "safer" as it checks that everything seems normal about the user's registration in the course.
The text was updated successfully, but these errors were encountered: