[IOI fork parity] cli script changes

[prandla]

• https://github.com/ioi-2024/cms/commit/9819be6ae2a1b44e87e16983ed23b2f213cdc168 "add option '--name' to ImportDataset"
• https://github.com/ioi-2024/cms/commit/c4bbefcde368470c08c8ac411285fa0ab4258f67 "Add -d/--default flag in cmsAddStatement to indicate is the statement is the default one"
• https://github.com/ioi/cms/commit/66bd28170a69d931927f5c0ef47ca905aacd2685 "cmsImportTask: Add -d/--dataset flag to indicate which dataset to upsert"

and some changes to cmsAddSubmission related to the ioisubmit tool:

• https://github.com/ioi-2024/cms/commit/acb638203dc87b5b80ec614971907fc3d6a1d09e "add the --lang parameter"
• https://github.com/ioi-2024/cms/commit/5979ed89b72da6d0c342bbaf58580195f4365361 "temporary hack for connecting to the ES"
• https://github.com/ioi-2024/cms/commit/ac1e42f4f85eae0942e0d0d11ee9c4a1d766d515 "check for submission limits"

the last two of which need to be implemented in a less hacky way.

[veluca93]

I'll leave it to @gollux to comment on the last 3 commits. The top 3 we should probably merge soon.

[gollux]

We should merge the --lang parameter.

ioi-2024@5979ed8 is a hack, but I don't have an idea how to solve it better. Perhaps somebody who knows the RPC mechanism better?

ioi-2024@ac1e42f: again, I would like to ask for opinions on how to solve it better.

[wil93]

My two cents:

• Adding lang parameter: we could disambiguate with an extra prompt (similar to what we do when calling cmsContestWebServer without specifying a contest ID when there are multiple contests). However I think it's fine to have the lang parameter too (it could be useful when calling AddSubmission as part of a script or a loop).
• Hack for ES: as I said before, we could replace the RPC system and simplify our architecture by using an existing job queue mechanism.
• Check submission limits: I think AddSubmission is a strictly admin-facing script that is not intended to be run by users. Why are we checking the submission limits? If we want to have a user-facing script, then it would anyway be better to do it as an interface to CWS (the only user-visible part of CMS) via REST API or something like that, and in that case the limits would be checked implicitly.

[gollux]

• lang: I don't think we should ask unsolicited interactive questions. It makes the program hard to use in automated ways. If the input is ambiguous, just fail.
• RPC: in the long run, possibly yes, but we need working cmsAddSubmission now.
• Submission limit: My use case is adding offline submissions made during the IOI using the backup submission mechanism. They count towards the submission limit.

[veluca93]

• lang: I don't think we should ask unsolicited interactive questions. It makes the program hard to use in automated ways. If the input is ambiguous, just fail.

+1

• RPC: in the long run, possibly yes, but we need working cmsAddSubmission now.
• Submission limit: My use case is adding offline submissions made during the IOI using the backup submission mechanism. They count towards the submission limit.

I am not sure I terribly like the idea of using cmsAddSubmission for this. Using the new CWS API would IMO be better, if there aren't strong reasons why it wouldn't work - wdyt?

[gollux]

Using the new CWS API would IMO be better, if there aren't strong reasons why it wouldn't work - wdyt?

It could be better if we figure out how to do the submission on behalf of a given contestant.

[veluca93]

If nothing else, we can log in as them at the end of the contest, right?

[gollux]

We would have to authenticate as the particular contestant (which probably means to keep a list of passwords and turn off IP-based restrictions) and somehow flag the submissions as official even though they are made after the contest ends.

We could extend the API and add authentication as an admin, which allows submissions on behalf of a given contestant, with the given value of the official flag.

I am not sure if it's not easier to use cmsAddSubmission though :)

[wil93]

I have an idea: we were always "defensive" and disallowed submissions unless some conditions were true (e.g. the contest was not over yet) but then we realized over time that it would have been better to "err on the side of caution", receive more submissions, declaring them "unofficial" (see the change where we allowed students to submit unofficially past the end of the contest).

Now, we could do the same for other conditions such as the max submission number. Why don't we simply turn the exceeding submissions into unofficial submissions? We could also make it so that the "unofficial" concept is computed automatically based on all the available information and criteria, thus making it work transparently with cmsAddSubmission. Then, once you load all submissions, you would have to go one by one to mark them as "official". They would be unofficial since we are submitting them manually, so the contest is finished, but for some of those there would be a "second reason" for being unofficial (e.g. submission 123 is unofficial because it was sent after the end of the contest, and because it exceeds the max amount of submissions). The contest admin (us, in this scenario) can then decide to make that submission official or not, given that information.

This would make the CWS check easier (we could remove it completely) but we should take care of cases like: if an Admin decides to increase the max_submissions_number, an unofficial submission would either become official (do we want that?) or at least "lose" one of the "unofficiality reasons" (fair enough).

[gollux]

The submission limit also serves as a guard against denial of service attacks (both intentional and random). Rejecting a submission costs the server much less than accepting it as unofficial.

[gollux]

cmsAddSubmission hacks are no longer needed for ioisubmit, but the --lang parameter is useful anyway.