24 lines
1.6 KiB
Markdown
24 lines
1.6 KiB
Markdown
# Team Cash Flow Presentation Design
|
||
|
||
## Goal
|
||
|
||
Display transaction amounts consistently from the team wallet's perspective in every modern-frontend transaction history.
|
||
|
||
## Semantics
|
||
|
||
- A player payment and a team-wallet credit are real inflows: green with an explicit plus sign.
|
||
- A team-wallet expense and a negative player-payment reversal are real outflows: red with a mathematical minus sign.
|
||
- Player fines, levies, fees, and player credits do not move team-wallet cash: grey and unsigned.
|
||
- Unknown transaction types are neutral to avoid claiming a cash movement that the application cannot prove.
|
||
- Player payouts remain general team-wallet expenses with the player's name in the note; no new transaction type is introduced.
|
||
|
||
## Design
|
||
|
||
Replace the existing debit-only amount helper with a context-aware cash-flow presenter. A shared standalone Angular component owns formatting, semantic color, signs, and accessible labels. Cashbox and overview activities pass `team` or `player` based on `isTeamWalletTransaction`; private and public player histories always pass `player`.
|
||
|
||
No backend API, database, balance calculation, booking form, balance card, or legacy-frontend behavior changes.
|
||
|
||
## Accessibility and Testing
|
||
|
||
The visible amount uses `+`, `−`, or no sign and Material semantic color tokens. The amount exposes an accessible German label identifying Einzahlung, Auszahlung, or keine Kassenbewegung. Unit tests cover numeric, string, and object transaction types plus reversals and unknown types; component and view tests prove consistent rendering in all four histories.
|