feat(notifications): drive the push hint from the backend provisioning flag#83
Merged
Merged
Conversation
…g flag The pushProvisioned param shipped with no producer: a host had to resolve push provisioning itself, and uptizm could not even pass it (the starter's own route builds the view). Meanwhile magic-starter-laravel now reports meta.push_provisioned on both preference responses. The controller reads that flag into pushProvisionedNotifier and the view renders the hint while it is false. The flag starts true and only moves on a response that actually carries a bool, so a backend that predates it never reads as 'push not configured'. The view param becomes bool? and means override: null (the default) reads the backend flag. The matrix and the flag ride one response, so the matrix builder now listens to both notifiers merged instead of the matrix alone; a flag that changes on a save rebuilds the toggles too.
There was a problem hiding this comment.
Pull request overview
This PR updates the notifications preferences flow so the “push not yet configured” heads-up is driven by a backend provisioning flag (meta.push_provisioned) instead of requiring host wiring, aligning the hint with the data source that owns the truth.
Changes:
- Add
pushProvisionedNotifiertoMagicStarterNotificationControllerand publishmeta.push_provisionedfrom both fetch (GET) and update (PUT) preference responses. - Update
MagicStarterNotificationPreferencesViewsopushProvisionedbecomes a nullable host override (bool?), defaulting to the backend-driven notifier, and rebuild the matrix UI when either the matrix or provisioning flag changes. - Expand controller + view test coverage for backend-true/false, missing flag degradation behavior, and host override precedence; update changelog entry accordingly.
Reviewed changes
Copilot reviewed 5 out of 5 changed files in this pull request and generated 1 comment.
Show a summary per file
| File | Description |
|---|---|
| lib/src/http/controllers/magic_starter_notification_controller.dart | Publishes meta.push_provisioned into a new pushProvisionedNotifier and disposes it with the controller. |
| lib/src/ui/views/notifications/magic_starter_notification_preferences_view.dart | Renders the push hint based on backend flag by default; supports host override via nullable pushProvisioned; listens to merged notifiers for rebuilds. |
| test/http/controllers/magic_starter_notification_controller_test.dart | Adds tests ensuring provisioning flag is published, retained when absent, and republished on save. |
| test/ui/views/notifications/magic_starter_notification_preferences_view_test.dart | Adds widget tests for backend flag true/false, degraded payload behavior, and override precedence. |
| CHANGELOG.md | Updates the unreleased entry to describe backend-driven provisioning behavior and the override semantics. |
Codecov Report✅ All modified and coverable lines are covered by tests. 📢 Thoughts on this report? Let us know! |
…he brand The lowercase 'onesignal' read like a misspelled brand name. It is the backend feature-flag identifier, so code-quote it and spell the brand properly where the docblock means the product.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What
MagicStarterNotificationControllernow readsmeta.push_provisionedoff both preference responses intopushProvisionedNotifier, and the preferences view renders the push heads-up while it isfalse.MagicStarterNotificationPreferencesView.pushProvisionedbecomesbool?and means OVERRIDE:null(the default) reads the backend flag.Why
#82 shipped the param with no producer. A host had to resolve push provisioning itself, and the most likely host could not even pass it:
/settings/notificationsis served by the starter's own route registration, so nothing constructs the view. The flag belongs with the data it describes, so magic-starter-laravel now returns it (fluttersdk/magic-starter-laravel#14) and every host gets the hint with no wiring and no extra request.Degradation
The flag starts
trueand only moves on a response that actually carries a bool, so a backend that predatesmeta.push_provisioned(or a degraded payload) never renders a false "push not configured" claim. Against an older backend the hint simply never shows.Notes
_buildMatrixSettingslistens to both notifiers merged rather than the matrix alone; a flag that changes on a save now rebuilds the toggles too.pushProvisionedNotifieris disposed withmatrixNotifier.dart formatclean.