Repository navigation
tech-debt(frontend): the display-name fallback is re-implemented six times with two extra rungs #14939
Description
Activity
Closing. Delivered by #16265, squash
4da66c79d9onDev_new_gui(landed in merge train #16339, tree-equal to its tested run). Each ask is verified on basea12b4bf79d:- One fallback ladder is decided, with an owner for each rung.
- The server owns the user-id rung.
autobot-backend/llc/api/companies.py:610haslist_membersreturningresolve_display_name(names.get(m.user_id), None, str(m.user_id)). That matches_compose_human_nodes(:1051,resolve_display_name(display_name, username, str(user_id))), sodisplay_nameis never null. - The frontend owns the render-time rule.
src/utils/displayName.ts'sdisplayNameOf()returnsdisplay_name || username || fallback.
- The server owns the user-id rung.
- The LLC endpoints agree, and there is one shared frontend helper.
- No
display_name || …user_idfallback is left inautobot-frontend/src(0 matches). displayNameOfis used atInviteUserDialog.vue:105,ShareKnowledgeDialog.vue:210andviews/llc/MembersView.vue:98.MembersView.vue:52anduseCompanyPeople.ts:83,88render the now server-resolveddisplay_namedirectly.ShareKnowledgeDialog's unique email rung is gone (0 matches).src/utils/__tests__/displayName.test.tspins the ladder.
- No
- No hardcoded UI strings.
AdminUsersView.vue:66rendersuser.display_name || t('adminUsers.displayNameNotSet'), and that key is present in 11 of 11 locale files. Its "not set" meaning is deliberate, because the column sits beside a separate username column.
Also seen:
AdminUsersView.vue:83still renders'—'for an empty voice-bundle cell. That's a different column, outside this issue's scope. It's a typographic placeholder rather than translatable text, which is why it isn't filed.- One fallback ladder is decided, with an owner for each rung.
Found while closing #13957 in #14936, which converged the five Python copies of this rule onto
UserCore.full_name/resolve_display_name(). The frontend half was out of that issue's stated scope.Gap
"Show
display_name, fall back tousername" is re-implemented in the frontend too, with two more fallback depths than the backend had:components/collaboration/InviteUserDialog.vueuser.display_name || user.usernameviews/llc/MembersView.vueu.display_name || u.usernameviews/llc/MembersView.vuemember.display_name || member.user_idcomposables/llc/useCompanyPeople.tsm.display_name || m.user_idcomponents/knowledge/ShareKnowledgeDialog.vueuserData.display_name || userData.email || userData.username || idviews/AdminUsersView.vueuser.display_name || '—'Root cause worth fixing first
The
|| m.user_idrungs exist because the two LLC endpoints disagree about who owns the last rung:list_memberscan returndisplay_name: nullfor a membership whose user row is gone, so the client has to invent a label._compose_human_nodesalready resolves that case server-side tostr(user_id).So the frontend compensates for one endpoint and duplicates the other. Aligning the two endpoints removes the reason for two of the six copies, and should happen before a shared frontend helper is written — otherwise the helper just encodes the inconsistency.
AdminUsersView's em-dash terminus is a separate divergence: it renders a blank-looking cell where every other surface renders a username.Ask
Related