kobotoolbox / kpi / 30332723373

82%

master: 76%

Build Type

push

github

Committed by web-flow

Commit Message

feat(assetVersion): add version_number to `/api/v2/assets/<uid>/versions/` DEV-1825 (#7300)

### 📣 Summary
This PR adds a `version_number` field to the asset versions API,
returning "12" for deployed versions and "11.4" for undeployed versions
(numbered relative to the deployment that precedes them), computed
server-side so the numbering stays correct regardless of pagination.

### 📖 Description
#### Why this needed to be done in the backend
The Form History UI (Project → Form tab) needs to label each version
like v12, v11.4, etc. - deployed versions get a whole "major" number,
and undeployed (draft) versions get a "minor" number counting up since
the last deployment.

The frontend currently derives this from array index, which only works
because the full list is loaded at once. We're moving this list to
paginated infinite scroll, and a version's correct number depends on the
entire history of the asset before it - not just the versions on the
current page. The frontend has no way to know, from a single page of
results, how many deployments happened earlier in history, so it can't
reliably compute this itself once pagination is introduced.

#### What changed
Added a `version_number` field to the versions serializer. For each
request, we fetch the asset's full version history as a lightweight (id,
deployed) list in a single ordered query, then walk it once in Python to
build a map of version id → label: deployed versions increment the major
number and reset the minor, undeployed versions increment the minor. The
serializer looks up each row's label from that map, so both the
paginated list endpoint and retrieve return identical,
pagination-independent numbers with no per-row queries.

#### Why computed on the fly instead of stored on the model
I considered storing these numbers as columns on AssetVersion, populated
at save time like the existing _content_hash field, but ruled it out
because the table has millions of rows and would need a long, risky
ba... (continued)

Coverage Stats

9534 of 12864 branches covered (74.11%)

28 of 29 new or added lines in 3 files covered. (96.55%)

4060 existing lines in 132 files now uncovered.

30866 of 37707 relevant lines covered (81.86%)

5.51 hits per line