Latent bug found while designing #873. ApproveParentalLinkCommandHandler.cs:33 builds Permissions = new FeaturePermissions { Chat = true, FileUpload = true, ... } explicitly — any field not listed gets the CLR default, not the entity default. InfoVault has entity default true but ends up false after link approval. Every future permission added with a non-false default will hit the same trap.
Fix: initialize from new FeaturePermissions() and override only the intended fields (or list every field explicitly with the entity defaults), plus a pinning test.
Latent bug found while designing #873. `ApproveParentalLinkCommandHandler.cs:33` builds `Permissions = new FeaturePermissions { Chat = true, FileUpload = true, ... }` explicitly — any field not listed gets the CLR default, not the entity default. `InfoVault` has entity default `true` but ends up `false` after link approval. Every future permission added with a non-false default will hit the same trap.
Fix: initialize from `new FeaturePermissions()` and override only the intended fields (or list every field explicitly with the entity defaults), plus a pinning test.
InfoVault is not listed, and its entity default is true (ProfileParentalSubDocuments.cs, [JsonProperty("infoVault")] public bool InfoVault { get; set; } = true;) — so link approval still silently flips it to false. The handler even carries a NOTE at :33-35 naming this ticket as open.
Important: the ExposeAgePublicly = false line at :45 was added by #873 and satisfies that ticket's item 9 only. It does not fix this one — it's another hardcoded field in the same wholesale replacement, which is the defect. Any future permission added to FeaturePermissions will be silently zeroed here too.
Remaining work: rebuild from new FeaturePermissions() and override only the fields this flow genuinely intends to set (or enumerate every field with its entity default), plus a pinning test — there is currently no test asserting unlisted permissions survive link approval, which is why this survived #873's review.
Re-verified against `origin/master` — **the bug is verbatim intact.** Staying open. Recording the exact state so this isn't mistaken for fixed-by-#873:
`SpikerSoft.Business/Domain/Profile/Commands/ApproveParentalLink/ApproveParentalLinkCommandHandler.cs:36-46`:
```csharp
childProfile.ParentalControls.Permissions = new FeaturePermissions
{
Chat = true, FileUpload = true, VideoCall = false, PublicProfile = false,
SocialFeatures = true, MaxDailyScreenTimeMinutes = 120,
ExposeAgePublicly = false,
};
```
`InfoVault` is not listed, and its entity default is `true` (`ProfileParentalSubDocuments.cs`, `[JsonProperty("infoVault")] public bool InfoVault { get; set; } = true;`) — so link approval still silently flips it to false. The handler even carries a NOTE at `:33-35` naming this ticket as open.
**Important:** the `ExposeAgePublicly = false` line at `:45` was added by #873 and satisfies *that* ticket's item 9 only. It does not fix this one — it's another hardcoded field in the same wholesale replacement, which is the defect. Any future permission added to `FeaturePermissions` will be silently zeroed here too.
Remaining work: rebuild from `new FeaturePermissions()` and override only the fields this flow genuinely intends to set (or enumerate every field with its entity default), plus a pinning test — there is currently no test asserting unlisted permissions survive link approval, which is why this survived #873's review.
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Latent bug found while designing #873.
ApproveParentalLinkCommandHandler.cs:33buildsPermissions = new FeaturePermissions { Chat = true, FileUpload = true, ... }explicitly — any field not listed gets the CLR default, not the entity default.InfoVaulthas entity defaulttruebut ends upfalseafter link approval. Every future permission added with a non-false default will hit the same trap.Fix: initialize from
new FeaturePermissions()and override only the intended fields (or list every field explicitly with the entity defaults), plus a pinning test.Re-verified against
origin/master— the bug is verbatim intact. Staying open. Recording the exact state so this isn't mistaken for fixed-by-#873:SpikerSoft.Business/Domain/Profile/Commands/ApproveParentalLink/ApproveParentalLinkCommandHandler.cs:36-46:InfoVaultis not listed, and its entity default istrue(ProfileParentalSubDocuments.cs,[JsonProperty("infoVault")] public bool InfoVault { get; set; } = true;) — so link approval still silently flips it to false. The handler even carries a NOTE at:33-35naming this ticket as open.Important: the
ExposeAgePublicly = falseline at:45was added by #873 and satisfies that ticket's item 9 only. It does not fix this one — it's another hardcoded field in the same wholesale replacement, which is the defect. Any future permission added toFeaturePermissionswill be silently zeroed here too.Remaining work: rebuild from
new FeaturePermissions()and override only the fields this flow genuinely intends to set (or enumerate every field with its entity default), plus a pinning test — there is currently no test asserting unlisted permissions survive link approval, which is why this survived #873's review.