Repository navigation
Merge/v1.12 into v2.0 - #563
Conversation
Mount app immediately then async load API data
371 site edit cancel
Start editing opens a chooser of the source's managed datastreams and their sessions: continue an in-progress session, start a new one over the selected time range, or create and delete managed datastreams. Managed datastreams are hidden from the catalog and reached through the chooser. Also adds inline processing-level creation, the session description captured at commit time, reuse of the source's loaded series as the working copy, clamping the session window to the source extent, and session resume that replays saved operations.
…eps nested relations
…-endpoints # Conflicts: # package-lock.json
Plot a QC session's state at any operation as a separate, frozen line so it can be compared against the session being edited. Buttons sit on every operation row and on the "Data loaded" row, which plots the state the session started from. Snapshots ride in plottedDatastreams under the synthetic id snap:<sessionId>:<opIndex>, so legend rendering, colour assignment, visibility and reorder work unchanged. isSnapshotId guards the paths that would otherwise treat one as real: refreshGraphSeriesArray skips its fetch, releaseManagedDatastream drops them when the editor closes, and the share encoder keeps them out of ds in favour of its own snap key. The base is always the session chain's own window, never the plot's time range, because operations replay against array indices. Snapshots build on a detached ObservationRecord since the observation store hands back one shared instance per datastream and the replay mutates what it is given. Also fixes two pre-existing problems in the history panel that this work surfaced: - Reloading from a step restored the pre-replay entries wholesale, which put the old timings back over the ones the replay had just measured. Only the "Data loaded" row updated. The panel now keeps the replayed entries and appends only what the replay dropped. - hasUnsavedChanges compared entries by identity, so a replay while viewing a committed session read as pending edits and prompted "You have unsaved edits". A committed session cannot be edited, so both it and unsavedEditCount now short-circuit on isReadOnly.
Covers the feature in the user guide, the id convention, guards and detached-fetcher rule in the architecture doc, the axis behaviour in the plotting doc, and the two new store actions in the API reference.
The Data loaded row is step -1, so a session's starting state is now reachable the same way any operation is, and it carries the "Showing" chip when it is the step on screen. Its reload-from-server button moves to a cloud icon so the row no longer shows two identical glyphs doing different things: one replays the history to a step, the other refetches and drops the history.
Save, Commit and Close now sit in a footer below the history and stay visible while it is collapsed. Also drops the author name from collapsed rows, puts the comment icon beside the operation title, and retitles reload-from-server to discard and reload, hidden on committed sessions.
… into 436-integrate-history-endpoints
…-endpoints # Conflicts: # django/contracts/openapi/auth.openapi.json # django/contracts/openapi/data.openapi.json # django/hydroserver/__init__.py # packages/hydroserverpy/setup.cfg
…ate-history-endpoints
Undo, redo, step reload, and removing an entry all rebuild each item from its method and args, which dropped the operator's comment and the server's attribution. Re-stamp both afterwards, paired positionally and only when the method still matches. Execution timings are left to be re-measured.
…ints [#436] Integrate history endpoints
Release/v1.12.0
|
@Maurier Can you review the changes to the QC app to make sure the 2.0 merge doesn't break anything? These are mainly changes to the API contract for v2.0 that had to be reconciled with the v1.12 QC app and qc-utils. In v2.0, the pattern for fetching nested collections of resources is different. With the way the QC API worked in v1.12, ported straight to v2.0, its not possible to fetch a history with all its sessions and operations in one request. The merge handles this by fetching operations for one session at a time for a given history. I could also flatten all the history endpoints to allow more flexibility in fetching operations across multiple sessions or histories in a single request. /quality-control/histories/items/{history_id}/sessions → /quality-control/sessions/items This would allow the QC app to fetch all operations for a given history using a historyId query parameter (instead of a path parameter), but its a bigger change to the API, so I wanted your thoughts on it before moving forward with that change. |
|
Yes, I'll take a look at this . |
daniel-slaugh
left a comment
daniel-slaugh
left a comment
There was a problem hiding this comment.
Looks to me like everything in v1.12 is working the same as before. I'd also support your proposed changes for flattened responses.
|
@daniel-slaugh Sounds good, I'll plan to flatten those endpoints in a follow-up PR. |
Fixed derivation tasks when input datastreams have different start times
Deploy v1 docs alongside v2 docs
3 participants
Uh oh!
There was an error while loading. Please reload this page.