Generic notifications

[HebaruSan]

Problems & motivations

KSP2 is now available and has been added to SpaceDock and is being added to CKAN.

SpaceDock's integration with CKAN is very hard-coded.

• A single Mod.ckan column tracks whether a mod is enabled for notifications, which cannot support multiple notification mechanisms per game
• A global create-url config setting controls where we send requests to add a mod, which cannot support different notification mechanisms for different games
• A global notify-url config setting controls where we send notifications that a mod has been changed, which cannot support different notification mechanisms for different games
• The templates have the literal string "CKAN" in them, which can't work for non-CKAN notifications
• The production game id of KSP1 is hard-coded in some of the code (!), which makes that part impossible to test properly in development servers

Aside from the inflexibility, there are also bugs:

• The CKAN checkbox doesn't show up for KSP2 mods during creation (good), but it does show up during edit (bad, and some KSP2 modders have been exploiting this to send KSP2 mods to the metadata repo for KSP1)

As a half step toward improving this, a ksp-game-id config setting exists to control which game is used by the game version import task, but this is obviously very tightly coupled to just one game.

Changes

• The Mod.ckan column is removed
• A new Notification table defines the notification endpoints for each game, including requests to add, change notifications, and game version listings
• A new EnabledNotification table links notifications to the mods for which they are enabled
• For mod creation, the static CKAN checkbox is now replaced by script-generated checkboxes based on /api/<game-id>/notifications when a game is selected, and the server code creates EnabledNotification rows as needed
• For mod editing, the static CKAN checkbox is now replaced by checkboxes generated by the template at load based on the notifications for the mod's game, and the server code creates and deletes EnabledNotification rows as needed
• A new Notifications tab in the admin pages allows the creation, editing, and deletion of Notification rows (so I don't have to request SQL commands to be run for basic maintenance tasks)
• /api/kspversions is retired in favor of /api/<game-id>/versions since we cannot easily say which game is "ksp"
• ckan.py is renamed to notification.py
• send_to_ckan is renamed to send_add_notifications and now loops over the mod's EnabledNotifications and sends to Notification.add_url
• notify_ckan is renamed to send_change_notifications and now loops over the mod's EnabledNotifications and sends to Notification.change_url
• The hourly scheduled task to import game versions now looks at all Notification rows with builds_url defined and uses them to retrieve versions for the corresponding games. Three formats are supported:
  • plain_current: A plain text string describing just the current version, intended for Juno: New Origins' web API
  • json_list: A JSON array of version strings, intended for CKAN's KSP2 builds.json file
  • json_nested_dict_values: A JSON object containing a property named after Notification.builds_url_argument, which contains an object with the versions as values of the properties, intended for CKAN's KSP1 builds.json file
• To make life easier for the CKAN team, the mod search now supports a notif:CKAN syntax so we can list mods with a given notification enabled

A migration is included to:

• Create the tables
• Create a Notification row with CKAN's settings for KSP1 using the ksp-game-id config setting
• Create a Notification row with CKAN's settings for KSP2 using the ksp2-game-id config setting (note that both new notifications are called "CKAN", because they both are CKAN, just with different URLs for different games)
• Create EnabledNotification rows for all mods that had Mod.ckan == True, with KSP1 mods being associated with the Notification for that game and KSP2 mods associated with the Notification for that game

Note that the commit has a different author because it originated in the branch from #274 and I've just been amending it.

Fixes #329. Closes #274.

Configuration

To make the migration auto-generate a CKAN entry for KSP2, we should add this to config.ini before upgrade (re-used from #479, which will probably be in the same cluster of changes and therefore mostly superceded):

ksp2-game-id = 22407

This setting and ksp-game-id can then both be discarded after the upgrade, since the Notification table's contents replaces them.

[HebaruSan]

The URLs in the migration are now backwards-compatible, and V1TA5 has set the KSP2 game ID in the config. Can now merge safely.