Details
-
Type:
Improvement
-
Status:
Closed
-
Priority:
Minor
-
Resolution: Won't Fix
-
Affects Version/s: Current Version
-
Fix Version/s: None
-
Component/s: OIOIOI
-
Labels:None
Description
We have many places around the system, where some submission status is defined:
- https://github.com/sio2project/oioioi/blob/master/oioioi/contests/models.py#L229 ,
- https://github.com/sio2project/oioioi/blob/master/oioioi/submitsqueue/models.py#L13 ,
-SIO-1293 ,
- ?????
This leads to many problems, like:SIO-1482 . Therefore, I think it would be a good idea to have one common place for submissions statuses and to keep them all hardcoded there.
- https://github.com/sio2project/oioioi/blob/master/oioioi/contests/models.py#L229 ,
- https://github.com/sio2project/oioioi/blob/master/oioioi/submitsqueue/models.py#L13 ,
-
- ?????
This leads to many problems, like:
Activity
- All
- Comments
- History
- Activity
- Transitions
- Commits
Hide
Maciej Matraszek
added a comment -
Permalink
Maciej Matraszek
added a comment - Submitsqueue define *states* not *statuses*. That's something really different, just like SubmissionReport.status and ScoreReport.status share common name, but nothing more – the former is a process, and the latter a result. How would you unify it?
Show
Maciej Matraszek
added a comment - Submitsqueue define *states* not *statuses*. That's something really different, just like SubmissionReport.status and ScoreReport.status share common name, but nothing more – the former is a process, and the latter a result. How would you unify it?
Maciej Matraszek
added a comment - Submitsqueue define *states* not *statuses*. That's something really different, just like SubmissionReport.status and ScoreReport.status share common name, but nothing more – the former is a process, and the latter a result. How would you unify it? "This leads to many problems, like: SIO-1482 " - Tomasz, it has nothing common with your conclusion.
I explained why belowSIO-1482 report.
Apart from above, this seems natural that statuses are registered in many modules. Statuses are dependent on the available functionalities which each module brings.
Turn off one module should hide statuses which are connected only with that module.
To my mind this report should be closed.
I explained why below
Apart from above, this seems natural that statuses are registered in many modules. Statuses are dependent on the available functionalities which each module brings.
Turn off one module should hide statuses which are connected only with that module.
To my mind this report should be closed.
Show
Michał Woś
added a comment - - edited "This leads to many problems, like: SIO-1482 " - Tomasz, it has nothing common with your conclusion.
I explained why below SIO-1482 report.
Apart from above, this seems natural that statuses are registered in many modules. Statuses are dependent on the available functionalities which each module brings.
Turn off one module should hide statuses which are connected only with that module.
To my mind this report should be closed.
Michał Woś
added a comment - - edited "This leads to many problems, like: SIO-1482 " - Tomasz, it has nothing common with your conclusion.
I explained why below SIO-1482 report.
Apart from above, this seems natural that statuses are registered in many modules. Statuses are dependent on the available functionalities which each module brings.
Turn off one module should hide statuses which are connected only with that module.
To my mind this report should be closed. 
