FeatureFlagsDialog leaves derived grace-stamp flags in overrides when unsetting runOpsMintKind and unlocks them when toggling read-only flags

Offen Anfängerfreundlich
  • Stimmt etwas nicht?
#5,062 0 Kommentare 0 Reaktionen 0 zugewiesene Personen Auf GitHub ansehen

Maintainer antworten meist innerhalb von 1 Tag

Dieses Issue hat noch niemand übernommen.

Bewertung

Schwierigkeit
2/5
Geschätzter Aufwand
1-3 Stunden
Anfängerfreundlichkeit
73/100
Issue-Typ
Bug
Klarheit
Klar beschrieben
Aktivitätsstatus
Aktiv
Tech-Stack
nextjs, typescript
Bereich
frontend

Rechercherichtung

Beginne in apps/webapp/app/components/admin/FeatureFlagsDialog.tsx und lies unsetFlag, derivedFlagsClearedWith und isLocked; prüfe, wie die v2-Aktion diese Flags beim Speichern behandelt. Aktualisiere das Dialogverhalten beim Zurücksetzen von runOpsMintKind und beim Bearbeiten abgeleiteter Flags. Prüfe anschließend, ob Vorschau und schreibgeschütztes Verhalten mit der gespeicherten Anfrage übereinstimmen.

Vom Indexierungsmodell aus dem Issue-Text verfasst.

Beschreibung

hey! noticed in a7f0f90e (apps/webapp/app/components/admin/FeatureFlagsDialog.tsx) that unsetFlag(key) only deletes overrides[key] and doesn't clear derivedFlagsClearedWith(key) (runOpsMintKindPrev and runOpsMintKindFlippedAt), so unsetting runOpsMintKind leaves its effect: "derived" grace-stamp rows highlighted in the dialog and visible in Preview JSON even though they have no unset button and withMintFlipGrace deletes them on save. also noticed isLocked (!unlocked && ORG_LOCKED_FLAGS.includes(key)) unlocks effect === "derived" rows into editable inputs when checking "Unlock read-only flags", even though the v2 action strips runOpsMintKindPrev and runOpsMintKindFlippedAt from the request body.

should unsetFlag also remove derivedFlagsClearedWith(key) from overrides and keep effect === "derived" flags read-only? happy to open a quick PR if you want!

ss
Image

Vorherrschende Sprache
TypeScript
Sterne
16.5k
Forks
1.5k
Ø Merge
1 T. 15 Std.
Gemergte PRs (30 T.)
17

Entwicklungsumgebung

Dieses Projekt bietet weder Dev-Container noch Dockerfile noch Beitragsleitfaden – die Einrichtung liegt bei Ihnen. Beginnen Sie mit der README; die allgemeinen Schritte stehen in unserem Leitfaden für den ersten Beitrag.

Erste Schritte

  1. Lesen Sie das ganze Issue und danach den Beitragsleitfaden des Projekts.
  2. Schreiben Sie ins Issue, dass Sie es übernehmen — das erspart doppelte Arbeit.
  3. Forken Sie das Repository und arbeiten Sie in einem Branch.
  4. Öffnen Sie einen Pull Request, der die Issue-Nummer nennt.

Mehr aus triggerdotdev/trigger.dev

Alle Issues in triggerdotdev/trigger.dev

Ähnliche Issues

Weitere Issues zu TypeScript

Neue Issues direkt in Ihr Postfach

Eine kurze Übersicht über anfängerfreundliche GitHub-Issues.