Data tables - sort, filter, pagination

@platform @ui
Feature: Data tables with sort, filter and pagination
  As a staff user
  I want to sort, filter, search and page any list
  So that I can find a record fast in a long table
  Every list in the product is searchable, sortable, filterable and paged, with one consistent look.
  Background:
    Given a list uses the shared table component

  Rule: Any list can be searched, filtered and sorted

    Scenario: Sort, filter and search a list
      Given a list of records
      When the user searches, filters and sorts it
      Then only the matching records are shown, in the chosen order

    Scenario: A filter that matches nothing
      Given a list of records
      When the user applies a filter that matches no rows
      Then an empty-result state is shown rather than the full list

    Scenario: An invalid filter is rejected
      Given a list of records
      When the user applies a filter the server does not accept
      Then the request is refused and the list is unchanged

    Scenario: Sorting cannot reach an unexposed column or row
      Given a list the user is authorised to see
      When the user sorts it
      Then sorting reorders only the rows already fetched and authorised, so it cannot reach a column or a row the user may not see

    Scenario: A search on a sensitive identifier matches only its last four digits
      Given a list with a sensitive numeric identifier column
      When the user searches by that identifier
      Then only the last four digits are matched, so a full value cannot be recovered

  Rule: The main screens fetch a bounded set and page in the browser; the API offers a cursor

    Scenario: A main list screen fetches a bounded set
      Given a main list screen
      When the list is loaded
      Then a bounded, scoped and filtered set is fetched, and the browser sorts and pages them

    Scenario: A very long feed uses keyset pagination in the API
      Given a very long feed served through the API, such as the document-request tracker
      When the next page is requested
      Then it loads by a cursor with a stable tiebreak key, so rows are not duplicated or skipped at the boundary

  Rule: One shared style keeps every table consistent

    Scenario: One style fix reaches every sortable table
      Given every sortable table uses the shared header component
      When the shared header style is changed once
      Then every table in the product picks up the change
    @edge-cases

    Scenario Outline: List behaviour at different sizes
      Given a list with "<rows>" rows and a filter of "<filter>"
      When the user views it
      Then the result is "<result>"
      Examples:
        | rows | filter | result |
        | none | a term | an empty-result state shown |
        | few | none | all rows shown, sorted and paged in the browser |
        | many | a term | matching rows, sorted and paged in the browser over a bounded, scoped fetch |
        | very many | none | the API serves pages by a cursor |