Overview
Part of #28 — Split GP Tracking feature.
Groups need an opt-in flag to enable split GP tracking. This is stored as a config key in the existing group_configurations table (same GroupConfiguration model already used for all per-group settings).
Work Required
Config key
- Key:
split_gp_tracking
- Values:
"1" = enabled, "0" or absent = disabled (default)
- No schema change needed —
group_configurations is a generic key/value table.
New Discord admin command: /toggle-split-tracking
File: commands/admin.py — ClanCommands extension
- Requires
ADMINISTRATOR permission (matches all existing group commands).
- Resolves
group_id from ctx.guild_id.
- Reads current value of the
split_gp_tracking config key for that group.
- Toggles it (
0 → 1 or 1 → 0), upserting a GroupConfiguration row.
- Responds with an ephemeral message: "Split GP tracking is now enabled / disabled for {group_name}."
Follow the pattern established by /reset-group-points (line 301) and /force-group-sync (line 357) for the DB lookup + config upsert.
Notes
- When a group disables this flag after it was previously enabled, no historical
drop_splits rows need to be cleaned up — they simply won't be queried for new drops and can be ignored in future Redis rebuilds for that group.
Overview
Part of #28 — Split GP Tracking feature.
Groups need an opt-in flag to enable split GP tracking. This is stored as a config key in the existing
group_configurationstable (sameGroupConfigurationmodel already used for all per-group settings).Work Required
Config key
split_gp_tracking"1"= enabled,"0"or absent = disabled (default)group_configurationsis a generic key/value table.New Discord admin command:
/toggle-split-trackingFile:
commands/admin.py—ClanCommandsextensionADMINISTRATORpermission (matches all existing group commands).group_idfromctx.guild_id.split_gp_trackingconfig key for that group.0 → 1or1 → 0), upserting aGroupConfigurationrow.Follow the pattern established by
/reset-group-points(line 301) and/force-group-sync(line 357) for the DB lookup + config upsert.Notes
drop_splitsrows need to be cleaned up — they simply won't be queried for new drops and can be ignored in future Redis rebuilds for that group.