Update and add new routes to view submissions.#438
Conversation
|
Thanks for the PR. But Why was this needed. Have a look at |
|
Oh. I just checked, I mistook the tries, which made me think it is a user and challenge pair and that it only gets updated. I can just make use of the existing table then... |
|
Cool, ping me when done |
ayu-ch
force-pushed
the
submissions-route
branch
2 times, most recently
from
c334ab7 to
34dcdf0
Compare
api/info.go
Outdated
| SolvedAt: submission.CreatedAt, | ||
| Flag: submission.Flag, | ||
| Success: submission.Solved, | ||
| Cheating: submission.Cheating, |
There was a problem hiding this comment.
Why are we showing to contestants that if this challenge is cheating or not?
There was a problem hiding this comment.
it is strictly for admin
There was a problem hiding this comment.
ALSO, Why are we showing points? Isn't it same for all always ?
| continue | ||
| } | ||
|
|
||
| submissionResp := SubmissionResp{ |
There was a problem hiding this comment.
Also, why do we need to return challName, Category, Tags, points, here? User queried using chall ID, so user already had all other details, so it is a waste.
There was a problem hiding this comment.
If struct change is not too much then only remove redundant feilds.
| } | ||
|
|
||
| submissionResp := SubmissionResp{ | ||
| UserId: submissionUser.ID, |
There was a problem hiding this comment.
FIx cheating here. Points make sense here, so your choice to keep it or remove it.
api/submit.go
Outdated
| CreatedAt: time.Now(), | ||
| UserID: user.ID, | ||
| ChallengeID: challenge.ID, | ||
| Solved: false, |
There was a problem hiding this comment.
Solved is also true in case of cheating.
There was a problem hiding this comment.
I don't think you should do this here. See the end of this function. It contains a lot of other preq like updating dynamic points and staling cache, etc. So, the solved:true version should be at end only.
core/database/challenges.go
Outdated
|
|
||
| err := Db.Table("user_challenges"). | ||
| Select("user_challenges.id as id, user_challenges.user_id as user_id, user_challenges.challenge_id as challenge_id, users.username as username, user_challenges.created_at as solved_at, user_challenges.flag as flag, user_challenges.solved as correct, user_challenges.cheating as cheating"). | ||
| Joins("JOIN users ON users.id = user_challenges.user_id"). |
There was a problem hiding this comment.
You are doing unneccessary join just for username which is not needed if you are passing userID.
There was a problem hiding this comment.
Same goes with challengesAttempt db cal
There was a problem hiding this comment.
I think when it comes to the QueryUserAttempts() function, we should remove the join, but for QueryChallAttempts() we would need it because we would have to make a call to get the username for who has solved anyways.
Signed-off-by: ayu-ch <ayu.chandekar@gmail.com>
Signed-off-by: ayu-ch <ayu.chandekar@gmail.com>
…from admin to public Signed-off-by: ayu-ch <ayu.chandekar@gmail.com>
Signed-off-by: ayu-ch <ayu.chandekar@gmail.com>
Signed-off-by: ayu-ch <ayu.chandekar@gmail.com>
Signed-off-by: ayu-ch <ayu.chandekar@gmail.com>
Signed-off-by: ayu-ch <ayu.chandekar@gmail.com>
ayu-ch
force-pushed
the
submissions-route
branch
from
34dcdf0 to
296c925
Compare
3 participants
Addition of new routes and features:
/api/info/submissions/challenge/:name-> Returns all submissions for a specific challenge. Admin sees all attempts including flags, whereas contestants just see the successful attempts without flag./api/info/submissions/user/:id-> Returns all submissions made by a specific user. Admin sees all attempts including flags, contestants see the successful ones without the flag.Cheating field in the submissions which the admin can use to filter cheated submissions on the frontend.