Follow-up from #38 (authoring-screens).
The Account settings screen has a working newsletter toggle that PATCHes /api/people/:slug/newsletter, but the read side never exposes the current opt-in state to the SPA. GET /api/auth/me returns the public Person shape (no newsletter); the people serializer hides newsletter from non-self callers.
Result: the Account screen defaults to optedIn=false and only reflects the server state after the user toggles once. That's a UX bug — a user who opted-in on a previous session sees a checkbox that lies until they touch it.
Fix
Add newsletter.optedIn (and probably email) to the self-view of GET /api/auth/me (and/or GET /api/people/:slug for self). The PATCH /api/people/:slug/newsletter response already returns the full newsletter shape, so the data is available — the serializer just needs to include it for self.
References
Follow-up from #38 (authoring-screens).
The Account settings screen has a working newsletter toggle that PATCHes
/api/people/:slug/newsletter, but the read side never exposes the current opt-in state to the SPA.GET /api/auth/mereturns the public Person shape (no newsletter); the people serializer hides newsletter from non-self callers.Result: the Account screen defaults to
optedIn=falseand only reflects the server state after the user toggles once. That's a UX bug — a user who opted-in on a previous session sees a checkbox that lies until they touch it.Fix
Add
newsletter.optedIn(and probablyemail) to the self-view ofGET /api/auth/me(and/orGET /api/people/:slugfor self). ThePATCH /api/people/:slug/newsletterresponse already returns the fullnewslettershape, so the data is available — the serializer just needs to include it for self.References
email(fetched from PrivateProfile) andnewsletterstate." (already in the spec; just unimplemented)