Should I merge it now? Yes.
I found no remaining blocking defect in the reviewed change.
You confirmed that the backend always includes active in validation responses. That resolves the missing-field concern. The inactive gate matches the confirmed response contract, and the white-label role check gives visiting creators the requested fan inbox.
GitHub merged this PR on 8 October 2026 at 13:03:53 IST. The merge commit is f8c26bd62d. This recommendation applies to the reviewed head fef2d53dd9.
The backend contract resolves the account-status concern
The backend team confirms that active is always present, as relayed by you on 8 October 2026. I accept that contract confirmation. I did not independently inspect a live response.
The isRecipientInactive getter checks !this.dmValidations.active for direct-message threads. An inactive recipient loses the composer. An active recipient keeps the existing permission and visibility rules.
The frontend type still marks active as optional. Making the type reflect the backend guarantee would improve clarity, but it is not a merge blocker.
The inactive check also locks sending, tipping, and paid-message unlocks through areMessageActionsLocked. That broader effect remains part of the reviewed behaviour. Broadcast and Followers threads skip this account-status gate.
What the rest of the change does
The account flag becomes a site-specific inbox role
The isCreator getter keeps creators in creator mode on TopFans. On a white-label site, it also requires is_host_owner or an owner identity match. A visiting creator gets fan mode. A non-creator stays in fan mode even if an owner flag is set.
Owner matching already supports the configured owner's gsi4pk and username, compared with the logged-in user's username, referral ID, or gsi4pk. The new role check reuses that existing logic. It agrees with the ownership approach in wls-owner.guard.ts.
The fan role reaches the request and the layout
getInboxTab() returns all for a visiting creator. getChatTypeIndex() uses the fan list slot, and updateActiveTab() chooses General. The three changed template classes also use this contextual role, so the visiting creator gets the fan spacing and tab layout.
The profile callback now filters tab options only for accounts whose stored is_creator is explicitly false. A visiting creator's options remain available internally, while the template hides the creator tab control. This avoids permanently deleting creator options just because the site context temporarily produces fan mode.
The role change also affects guaranteed replies
This getter has consumers outside inbox rendering. For a visiting creator, history handling clears creator pending-reply state and shouldFulfillGuaranteedReply() returns false. That follows the requested fan treatment, but it deserves an account-level smoke check. The change is not limited to hiding Priority and Message Lists.
Broadcasts retain their composer
shouldIncludeMessageValidation() excludes both existing forms of Broadcast and Followers. The inactive gate therefore ignores stale direct-message validation in those threads. A confirmed inactive direct-message recipient loses the footer; a recipient with active: true keeps the previous footer rules.
Behaviour checks
All 17 checks pass. These checks execute methods and getters extracted from the reviewed source. They use plain profile and validation fixtures. They do not call the backend or render the signed-in Angular page.
| Scenario | Reviewed result |
|---|---|
| Creator on TopFans | Creator role, Priority inbox available. |
| Creator visiting another owner's white-label site | Fan role, all inbox, fan list slot. |
| White-label owner identified by host-owner flag or matching account ID | Creator role retained. |
| Fan account | Fan role retained. |
Direct-message validation has active: false | Inactive, actions locked. |
Direct-message validation has active: true | Inactive gate stays open. Loading and failure still lock actions. |
Direct-message validation omits active | Inactive, actions locked. Synthetic fixture outside the confirmed backend contract. |
| No validation object yet | Inactive getter returns false. Permission loading still locks actions. |
| Broadcast or Followers with stale inactive validation | Inactive getter returns false. |
| Visiting creator with a pending guaranteed reply | Creator fulfillment is disabled by the fan role. |
Evidence and limits
I reviewed the complete base-to-head diff, the existing owner guard, inbox selection and indexing, validation handling, guaranteed-reply consumers, and the paid-attachment click guard. The diff passes the whitespace check.
GitHub lists one approval for this head and no check runs in its PR check summary. You confirmed that build and TypeScript checks ran before committing. I stopped pursuing those checks at your request. An earlier TypeScript and template check had passed locally, but the build I started has no confirmed completion result.
No live validation response, signed-in creator or fan session, payment, mobile interaction, or generated white-label build was exercised. The reviewed Angular configuration contains only the TopFans project. The fixture checks cover main-site and white-label role logic; they do not prove a deployed tenant behaves correctly.
After deployment, check active and inactive recipients on TopFans and a white-label site. Check a visiting creator, the host owner, and a fan account. Confirm that the composer and paid-message controls follow the account status.