Summary
code/DHMemberPortal/templates/dashboard_profile.html:63 reads `{{ identity.email or session.email or 'Not available' }}`.
Neither data shape the template receives has an `email` key:
- Raw identity JSONB has `emails` (array of `{type, email_address}`)
- `v_member_info` view has `primary_email` (the flattened primary address string)
So `identity.email` is always falsy and the template silently falls back to `session.email`. Users see the correct value today because the fallback works, but the template is reading the wrong key.
Fix
Change the expression to use the actual key. If the template is fed v_member_info data (which is the case today — `member_profile()` view passes the identity sub-dict of `get_full_member_info`), use `identity.primary_email`:
```jinja
{{ identity.primary_email or session.email or 'Not available' }}
```
If the data source is ever switched to raw identity, the expression becomes slightly more complex (pick the `primary`-typed entry from the `emails` array). Either way, fix the dead expression.
Context
Pre-existing; noticed during the #245 / #246 profile-save investigation. Cosmetic — no visible bug to users — but the template is relying on a fallback that masks the real bug.
Summary
code/DHMemberPortal/templates/dashboard_profile.html:63 reads `{{ identity.email or session.email or 'Not available' }}`.
Neither data shape the template receives has an `email` key:
So `identity.email` is always falsy and the template silently falls back to `session.email`. Users see the correct value today because the fallback works, but the template is reading the wrong key.
Fix
Change the expression to use the actual key. If the template is fed v_member_info data (which is the case today — `member_profile()` view passes the identity sub-dict of `get_full_member_info`), use `identity.primary_email`:
```jinja
{{ identity.primary_email or session.email or 'Not available' }}
```
If the data source is ever switched to raw identity, the expression becomes slightly more complex (pick the `primary`-typed entry from the `emails` array). Either way, fix the dead expression.
Context
Pre-existing; noticed during the #245 / #246 profile-save investigation. Cosmetic — no visible bug to users — but the template is relying on a fallback that masks the real bug.