feat(data): PowerUse-Flags und konfigurierbares Handoff-Budget
app_settings bekommt power_use_enabled (Master-Schalter, wird im Usage-Monitor gesetzt) und list_handler_max_handoffs (Default 4 = zwei Merge-Runden). list_config bekommt power_use_allowed als Opt-in pro Liste. Ein Handler-Run laeuft nur unbeaufsichtigt, wenn BEIDE Schalter gesetzt sind. Damit kann der globale Schalter ueber Nacht an bleiben, ohne dass der Handler einer nicht zugestimmten Liste sein Verhalten aendert. UpdateListConfigDto.PowerUseAllowed ist bewusst bool? (tri-state, null = gespeicherten Wert behalten), analog zu TicketProjectId: SetConfigAsync kopiert verbatim, ein non-nullable bool haette jedem fremden Writer erlaubt, das Opt-in per Auslassung zu widerrufen. Der Test dazu nagelt genau das fest. Migration ist drei reine ALTER TABLE ADD COLUMN, kein Table-Rebuild.
This commit is contained in:
@@ -17,6 +17,12 @@ public sealed class ListConfigEntity
|
||||
// Feld mitführen, sonst setzt es sich still zurück.
|
||||
public int? TicketProjectId { get; set; }
|
||||
|
||||
// Per-Liste-Opt-in für PowerUse. Ein Handler-Run läuft nur unattended, wenn BEIDES gesetzt ist:
|
||||
// dieses Flag und AppSettingsEntity.PowerUseEnabled. Der globale Toggle bleibt damit gefahrlos
|
||||
// an — eine Liste, die hier nicht zugestimmt hat, behält das interaktive Verhalten. Default
|
||||
// false, also opt-in. ⚠️ Gleiche Falle wie TicketProjectId: SetConfigAsync kopiert verbatim.
|
||||
public bool PowerUseAllowed { get; set; }
|
||||
|
||||
// Navigation property
|
||||
public ListEntity List { get; set; } = null!;
|
||||
}
|
||||
|
||||
Reference in New Issue
Block a user