a2n-seattle / a2n-seattle/rms-app

Display Cognito name attribute for Borrower/Owner (fall back to email)

Aberta
#358 2 comentários 0 reações 0 responsáveis Ver no GitHub
idea priority-medium
Linguagem predominante
TypeScript
Estrelas
1
Forks
1
Merge médio
27min
PRs com merge (30d)
4

Descrição

# Why?

**As a** user viewing items, reservations, or history
**I want** to see people's actual names instead of raw email addresses
**So that** the UI is more readable and matches how the org actually refers to people.

# What?

Everywhere the frontend currently renders a `borrower`/`owner` (or similar user-identifying) field as a raw email string — item detail pages, dashboard tabs (Currently Borrowed/Owned/Scheduled/History), resources table, reservation lists — resolve it to that person's Cognito `name` attribute instead, falling back to the raw email if:
- No Cognito user exists for that email, or
- The user's Cognito profile has no `name` attribute set.

Likely needs a small backend or BFF-layer helper (e.g. a batched Cognito `AdminGetUser`/`ListUsers` lookup, cached per-request or short-TTL to avoid a lookup per row) rather than doing this per-component on the frontend, since `web/` doesn't have direct Cognito admin access today. Consider whether this belongs as a new small API (e.g. `ResolveUserNames`) that batches a list of emails into a list of display names, called once per page render rather than N times.

# Testing

Unit test for the resolution helper (found → name, not found → falls back to email, profile exists but no name attribute → falls back to email). Jest/RTL test confirming the table/detail components render the resolved name.

# Additional context

Cognito admin lookups need appropriate IAM permissions from whichever Lambda performs them — confirm the relevant function's execution role allows `cognito-idp:AdminGetUser` or `cognito-idp:ListUsers` as part of implementation.

Guia de contribuição

Nenhum guia de contribuição indexado para este repositório

Direção de pesquisa

Analise os componentes frontend que renderizam os campos borrower/owner (detalhes do item, abas do dashboard, tabela de recursos, listas de reservas). O backend provavelmente precisa de um novo API endpoint ou BFF helper que faça o agrupamento das consultas de e-mail usando Cognito, AdminGetUser ou ListUsers. Verifique as permissões de IAM da Lambda relevante. Escreva testes unitários para a lógica de resolução e testes Jest/RTL para os componentes de UI.

Escrita pelo modelo de indexação a partir do texto da issue.

Avaliação

Stack de tecnologia
aws
Domínio
api, backend, frontend
Tipo de issue
Funcionalidade
Dificuldade
4/5
Tempo estimado
3-5 dias
Status de atividade
Pouca atividade
Clareza
Razoavelmente clara
Facilidade para iniciantes
45/100

Receba novas issues na sua caixa de entrada

Um resumo curto de issues do GitHub para quem está começando.