wbDesign Wiki
Storybook

Repair Requests Screen

Скачать .md ↓

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 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 owns the shell navigation visuals and emits the fixed repair-and-maintenance item; the shell owns the route mapping. [S8] [S9]
  • Main Container owns the shared desktop frame and vertical scrollport. [S1]
  • Header Widget receives the title and the Создать заявку action. [S3]
  • Table receives explicit columns and rows; Table Cell renders text, number, badge, link, and action data. [S2] [S3]
  • Projected Filter Row 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]

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); 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.

WB Logistics · Design SystemСборка 91da5ae

Поиск по Wiki

Начните вводить название или текст