API GenerateStandings does not respect Scoreboard Freeze

[clevengr]

Describe the issue: The PC2 API represents a contest as an instance of pc2.api.IContest. Interface IContest defines a method getStandings() which returns an array of IStanding. This is the method which API clients call to obtain current scoreboard standings.

The API implementation of interface IContest is class pc2.api.implementation.Contest. This class instantiates a pc2.api.implementation.GenerateStandings object and uses it to obtain the standings when IContest.getStandings() is invoked. Each time GenerateStandings.getStandings() is invoked it creates a new instance of DefaultScoringAlgorithm and uses it to obtain a new XML string giving the standings.

The instance of DefaultScoringAlgorithm which is created by GenerateStandings defaults to obeyFreeze=false. This means that the standings returned by the API are current (real, live). Any client which connects through the API (for example, the EWTeam) can therefore see the unfrozen standings.

To Reproduce:

• start a contest with a configured scoreboard freeze
• configure a webserver with the EWTeam
• wait until after the scoreboard freeze period starts
• submit a "yes" solution after the scoreboard is frozen
• login using the EWTeam
• examine the scoreboard displayed by the EWTeam The scoreboard on the EWTeam will show the Yes solution submitted after the freeze.

Expected behavior: Teams should not be able to see the live standings when a scoreboard is frozen.

Actual behavior: Teams can see live standings during the scoreboard freeze.

Additional context: It may be that a fix is as simple as calling setObeyFreeze(true) in GenerateStandings.getStandings().

[clevengr]

Something that needs to be checked is whether this bug exists in the new WTI Scoreboard implementation (see https://github.com/pc2ccs/pc2v9/issues/75). The issue likely still exists there because the WTI uses the PC2 API to obtain contest state -- so it may be the case that the WTI Scoreboard currently is always the live, unfrozen scoreboard. This would be very bad.

If on the other hand the WTI Scoreboard update (Issue 75) somehow fixed this issue, the the problem only exists with the old EWTeam (plus of course any third-party users of the PC2 API, but we don't know of any such at this time). This would make it much less of a priority to fix (although it still should be fixed).

[clevengr]

Further investigation appears to reveal that this bug is NOT present in the WTI implementation. Specifically:

• Access to standings in the WTI is managed through the /scoreboard REST endpoint, which is implemented by method getStandings() in class controllers.ContestController in the WTI project.
• The WTI ContestController constructor instantiates its own copy of class DefaultScoringAlgorithm, and sets it to "obey freeze" by calling dsa.setObeyFreeze(true);.
• Any time a user (team) invokes the /scoreboard getStandings() method, that method returns the results obtained by calling dsa.getStandings(), which in turn respects the obeyFreeze setting.

So this bug IS a problem with the EWTeam scoreboard, as well as with any new clients which directly use the PC2 API. However, it's not present in the current WTI implementation.

For more details on the WTI Scoreboard implementation, including insight as to how the WTI avoids the PC2 API bug, see this wiki page, noting in particular the instance of DefaultScoringAlgorithm imbedded within the WTI project.