Skip to content

fix(public-toc): show the author's name instead of the raw creator username - #707

Merged
likhithThammegowda merged 2 commits into
masterfrom
fix/public-toc-author-name
Aug 4, 2026
Merged

fix(public-toc): show the author's name instead of the raw creator username#707
likhithThammegowda merged 2 commits into
masterfrom
fix/public-toc-author-name

Conversation

@likhithThammegowda

Copy link
Copy Markdown
Contributor

The public course overview showed the internal creator username — creatorjhpaastrika_0qfj — where the signed-in course page shows Jhpiego Cooperation. It now shows the same name. Release notes for 4.2.11 ride along on this branch.

Why it isn't a one-line copy

The signed-in TOC renders content?.content?.creatorDetails[0]?.name. Copying that expression here would have rendered nothing.

That expression only works there because app-toc-home parses the field first:

if (this.checkJson(data.content.data.creatorDetails)) {
  data.content.data.creatorDetails = JSON.parse(data.content.data.creatorDetails)
}

The public page is fed by the public search API, which returns creatorDetails as a JSON string. Verified against the live payload for do_1146265657225789441402:

typeof: string
raw:    "[{\"id\":\"28ec6b71…\",\"name\":\"Jhpiego Cooperation\"}]"
naive creatorDetails[0]?.name  →  undefined       ("[" has no .name)

The content service returns the same field already parsed, so the getter handles both shapes and falls back to creator when the details are malformed or absent — it can never render less than before.

Verification

  • Production build green (yarn run build:local, exit 0)
  • public-toc-banner.component.spec.ts 13/13, including 7 new cases covering both payload shapes plus malformed, absent, no-name and null-content
  • Confirmed on the running app before release

Risk

Low. Confined to the public course overview banner and fallback-guarded, so the worst case is the previous behaviour.

…ername

The public course overview rendered `content.creator`, which is the internal
username (e.g. `creatorjhpaastrika_0qfj`). The authenticated TOC shows the human
name from `creatorDetails[0].name` — "Jhpiego Cooperation" — and the public page
should match.

Copying that expression verbatim would have rendered nothing. The authenticated
TOC works only because app-toc-home parses the field first; this page is fed by
the public search API, which returns `creatorDetails` as a JSON **string**, so
indexing it yields "[" and then undefined. The content service returns the same
field already parsed, so the getter handles both shapes and falls back to
`creator` when the details are malformed or absent — it can never render less
than it did before.

Verified against the live payload for do_1146265657225789441402, where
creatorDetails is the string '[{"id":"28ec6b71…","name":"Jhpiego Cooperation"}]'.
@likhithThammegowda
likhithThammegowda merged commit 2893947 into master Aug 4, 2026
1 check failed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants