Просмотр исходного кода

Document that execution time sorts and filters differently

The jobs list sorts by the displayed value, so a running job orders by how
long it has been going, while execution_time__gte/__lte match only the
recorded column — a long-running job can therefore top a descending sort yet
be excluded by a filter on the same attribute.

Keeping the filters on the stored column is deliberate: the filterset is
shared with the REST API, where matching against a live, clock-dependent
value would make results non-reproducible. Document the distinction, along
with the export's use of the recorded value, rather than reconciling them.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Jeremy Stretch 2 недель назад
Родитель
Сommit
7f91228fbf
1 измененных файлов с 3 добавлено и 0 удалено
  1. 3 0
      docs/models/core/job.md

+ 3 - 0
docs/models/core/job.md

@@ -35,6 +35,9 @@ The amount of time the job spent executing, calculated as the difference between
 !!! warning "The duration property is deprecated"
     The job model's `duration` property, which returned a preformatted string such as `5 minutes, 3.00 seconds`, has been **deprecated** and is planned for removal in NetBox v5.0. Export templates and plugins should reference `elapsed_time` instead, which returns a duration rather than a string and which also reports progress for a job that is still running.
 
+!!! note "Filtering and sorting behave differently"
+    Filtering on execution time matches only the recorded value, so a job which is still running is never returned: it has no execution time yet. Sorting the jobs list by the **Execution Time** column instead orders by the value displayed, which for a running job is the time elapsed so far. A long-running job therefore appears near the top when sorting in descending order, but is excluded by a filter on the same attribute. Exports likewise carry only the recorded value, in seconds.
+
 ### User
 
 The user who created the job.