# Repair Requests Screen ## Readiness | Dimension | Status and evidence | | --- | --- | | Specification | Current description of the team's local desktop prototype; production roles and business rules are not defined. [S2] [S3] | | Figma | Earlier reference: [S4] and `repair-requests.figma-target.json`. Neither was freshly verified against Figma in D-026; they do not prove parity with current local code. | | Local prototype | Implemented at `/`: 23 fixture rows, 13 columns, local filters, and owned design-system composition. [S2] [S3] [S6] | | Verification | D-026: `npm test -- --watch=false` passed (56 files, 535 tests). D-031 later ran application and Storybook builds plus Browser QA at 1440×900 and 1920×1080 for the shared shell; no fresh Figma comparison is claimed. [S5] | ## Purpose `/` is a desktop local prototype for inspecting repair requests. It composes the owned Sidebar, Header Widget, filters, and a 13-column Table. All records are fixtures; no backend calls, persistence, permissions, or production destinations are defined. These are the team's generated components in this repository, with no asserted mapping to developers' production components. [S1] [S2] [S3] ## Source and Route - Route: `/` in `src/app/app.routes.ts`. [S6] - Shell: `WblSidebarComponent` and `WblMainContainerComponent` in `src/app/app.component.*`; the shell handles `collapsedChange` and gives the main container the sole vertical scrollport. [S1] - Entry point: `Заявки на ремонт` is the third child of `Ремонт и ТО`, directly after `Ремонтные листы`. Selecting it maps to `/`; the group follows `Логистика внутренняя` and uses the `repair` icon. [S8] [S9] - `Аналитика ремонтов` is the first sibling in that group, but is a planned visual-only entry: it has no route, screen, or navigation outcome in this prototype. [S8] [S9] - Screen: `src/app/features/repair-requests/repair-requests.component.*`. [S2] [S3] - Component owners: current `src/app/design-system` and the local inventory. The immutable Source snapshot is historical migration evidence. - Prior design reference: [Repair Requests target](repair-requests.figma-target.json) and [S4]. The target describes earlier fixtures and assembly; it is not a current runtime contract. For example, its 11-row fixture differs from the current 23-row local fixture. [S2] ## Primary Scenario 1. The user opens `/` and sees the owned Sidebar with `Заявки на ремонт` in the `Ремонт и ТО` group and the `Заявки на ремонт` header. [S1] [S3] [S6] [S8] 2. The Table receives 23 fixture rows and 13 columns. The ID column requests initial descending sorting; the owned Table sorts locally with pagination hidden and keeps edge columns fixed within horizontal overflow. [S2] [S3] [S7] 3. Request-ID range, creation-date range, status, vehicle, and optional depot filters update computed local rows without a network query. [S2] [S3] 4. Reset clears filter state and hides the optional depot filter. Create, download, and row actions are visual stubs; the feature binds no business handlers or destination routes for them. [S2] [S3] ## Alternate Scenarios - A filter combination with no matching rows selects the Table's filtered-empty state. [S2] [S3] - `Автоколонна` may be added as an optional filter; removing it clears its selected depot. [S2] [S3] - Vehicle filtering permits multiple selections. [S2] [S3] ## Components and Accessibility - [Sidebar](../components/organisms/sidebar.md) owns the shell navigation visuals and emits the fixed repair-and-maintenance item; the shell owns the route mapping. [S8] [S9] - [Main Container](../components/atoms/main-container.md) owns the shared desktop frame and vertical scrollport. [S1] - [Header Widget](../components/organisms/header-widget.md) receives the title and the `Создать заявку` action. [S3] - [Table](../components/organisms/table.md) receives explicit columns and rows; Table Cell renders text, number, badge, link, and action data. [S2] [S3] - Projected [Filter Row](../components/organisms/wbl-filter-row.md) controls are Range, Calendar Range, and Select dropdowns. [S3] - Table, rows, and icon-only actions receive Russian accessible labels. Status is conveyed by text as well as color. This source inspection does not prove the full keyboard or assistive-technology journey. [S2] [S3] ## States, Errors, and Edge Cases - Populated and filtered-empty states are wired to static local data. [S2] [S3] - Reset is disabled when no filter value is applied. [S2] [S3] - Repeated request IDs exist in the fixture; the Table row ID also includes the fixture index to keep row identity distinct. [S2] - Calendar `today` and reference date are fixed at `2026-05-02` for this fixture. [S3] ## Data and Integration Boundary - Fixture links use `href="#"`; no details route is implemented. [S2] - Backend contracts, persistence, permissions, pagination, loading, error, and access-denied scenarios are not part of this prototype. [S2] [S3] - The current table mapping displays one leading vehicle icon and standard text/description fields. Earlier target details do not override local code. [S2] - No production integration or developer transfer is scheduled by this spec. ## D-039 Filter Row behavior The permanently visible request-ID range, creation-date range, status, and vehicle filters are `pinned`; `Автоколонна` is `optional`. The screen owns one controlled `openedFilterId`: opening a new control closes an empty depot control, and closing an empty optional depot control removes it. A depot with a selected value remains visible until its semantic `remove` action. Pinned actions reset only their screen-owned fixture values. Full reset clears every value, removes the optional depot control, and closes every overlay. These filters update only the existing 23 local rows; no backend, persistence, or production filtering is introduced. [S2] [S3] [S5] ## Related Flows No cross-screen business flow is defined. The Sidebar exposes the two implemented repair destinations, `/` and `/repair-sheets`, without shared data or action state. `Аналитика ремонтов` remains planned and visual-only until a later authorized task defines its screen and route. [S8] [S9] ## Verification D-026, 2026-09-05: `npm test -- --watch=false` passed 56 files / 535 tests; that historical suite result predates D-039. The current focused screen spec covers status filtering/reset, lifecycle-controlled pinned and optional filters, and the three row-action helper labels. [S5] The screen tests do not exercise every dropdown, sorting, action execution, or Figma parity scenario. D-031 Browser QA verified the shared shell at 1440×900 and 1920×1080: no global horizontal overflow, vertical scrolling in Main Container, and horizontal Table overflow preserved within the table region. ## Open Questions - Which additional fixture states or local visual actions should be modeled? - Figma assembly owners and screen parity need exact-node evidence before any new claim of visual verification. - Production data schemas and action destinations remain unspecified. - The planned repair-analytics entry needs a screen, route, data boundary, and navigation outcome before this prototype can describe it as implemented. ## Documentation Review Readiness review: D-026 ([GitLab task](https://gitlab.com/polozovdaniel/logistics-2/-/work_items/28)); verified member `danil-lebedev` / GitLab `8269564`; agent `codex`; session `01a0725e-9ce7-7070-bd66-3b8a92ab9006`. This review inspected tracked local sources; it did not re-verify Figma or establish production behavior.