fix(openchallenges): remove usage of "Other" for platform

[vpchung]

Fixes #2385

Changelog

• remove "Other" from list of platforms
• replace challenge.platform_id for "Other" (14) with NULL (\N)

Preview

Landscape now shows 13 platforms

"Other" no longer shows in platform facet

Platform info shows "Not available" in profiles for challenges hosted on non-OC platforms

[tschaffter]

@vpchung What about representing missing values by an empty string in the OC Data sheet and settings the default value of the SQL property challenge.platform to NULL? If that works on the SQL side, this could help make the OC Data sheet less cluttered and reduce the size of the CSV files tracked on GitHub.

[vpchung]

I don't think this will work, at least, not for the dump files to dump properly. If some rows contain less columns than other rows, then that row's data will be offset. But willing to try to see.

[rrchai]

The updates on API descriptions regarding of removing "Other" option of platform are pushed in this pr.

Initially, I considered removing the slug of the platform and allowing the challenge service to generate the slug automatically in the backend. However, this might also require removing the 'slug' column from the data.

To keep things simple, I've restricted the options to both the slug and name fields of the platform. @tschaffter Please let me know if there are any issues.

[tschaffter]

Initially, I considered removing the slug of the platform...

What is the problem with the platform slug? Isn't it enough to set the challenge.platform property to nullable in the API spec?

[rrchai]

What is the problem with the platform slug? Isn't it enough to set the challenge.platform property to nullable in the API spec?

It is enough with nullable challenge.platform. I thought we would like to limit options using these known platforms as a validation. If not restricting platform options using enum in API description, I think we should have a validation in the backend/frontend (in addition to data) to exclude unknown platforms?

[tschaffter]

Because the platform data live in the DB, we shouldn't do any validation in the spec, which would require us to update the API description each time we add/update platform data in the DB.

[tschaffter]

@vpchung Could you please resolve the conflict in challenges.csv? Thanks!

[vpchung]

@tschaffter done ✅

[tschaffter]

I updated the challenge service with the generator and weird things are happening like the challenge platform Java and TS object loosing some of its properties. Could this be a side effect of @rrchai using AllOf to make challenge.platform nullable? Currently investigating...

I also tried this solution described here (for OpenAPI 3.1) but this leads to the same behavior as when using Rong's solution (for OpenAPI 3.0 according to the SO post):

  platform:
    anyOf:
      - $ref: SimpleChallengePlatform.yaml
      - type: 'null'

Update: We are using OpenAPI 3.0.3! Previous attempts to move to OpenAPI 3.1 failed a few months ago at the level of code generation (see #1136). I should try again early next year.

[tschaffter]

@vpchung I fixed the styling issue visible on your screenshot where "Not Available" is not greyed out for platform. Now that platform is nullable AND optional, the property in TypeScript is:

platform?: SimpleChallengePlatform | null;

The styling check should check for these two values:

<td [ngClass]="{ 'text-grey': challenge.platform?.name === (undefined || null) }">

which I propose to simplify to the following:

<td [ngClass]="{ 'text-grey': !challenge.platform }">

[vpchung]

Works on my end! Thanks, @rrchai @tschaffter