Alpha collections - #243
Conversation
…acking-service into alpha_collections
Diagram showing the processes and Key Identifiers in the Lifecycle of Waste
…acking-service into alpha_collections
Updated the description to clarify the API's purpose and development context.
Reformatted the description for better readability.
Removed redundant text and clarified descriptions in the OpenAPI specification.
…acking-service into alpha_collections
| drop-off per Movement, even if the loads physically arrive together. | ||
|
|
||
| <a id="d-011"></a> | ||
| ### Static and transit collection collapsed into a single endpoint |
There was a problem hiding this comment.
When the collection is in transit, the user must be required to enter the details of the carrier the waste is being received from (this is different from static collection). So long as this requirement is met, I do not mind the implementation choice
There was a problem hiding this comment.
@perry-ellismay great, I am going to update the collection endpoint to support "transit" collection between carriers/drivers
There was a problem hiding this comment.
will this be a sub resource? or data item?
There was a problem hiding this comment.
I would prefer to see it as a collection "driver-to-driver" instead of "producer-to-driver", but I need to see how to shape the data in the best possible way
| but is not a v1 priority. | ||
|
|
||
| <a id="d-033"></a> | ||
| ### Per-event GET endpoints — parked |
There was a problem hiding this comment.
Get endpoint has got to be in scope, its crucial for operators to fulfil their DoC.
e.g. Waste arrives and they are given an ID, they need the ability to retrieve the details about that waste
There was a problem hiding this comment.
I agree, we need to define together what to return from each endpoint
| is clear. | ||
|
|
||
| <a id="d-021"></a> | ||
| ### Cross-check granularity |
There was a problem hiding this comment.
This forms most of the discussion around reclassification so should hopefully have an answer on this soon
AWDMcIntyre
left a comment
AWDMcIntyre
left a comment
There was a problem hiding this comment.
On D-028 — the note assumes Movement IDs are “created earlier, usually with signal.” Worth flagging that’s often not the case. My own work is mainly pre-planned hazardous collections (created days ahead, but a fair number of customers ring during the day and if it's non haz I’ll have the driver swing past on-route to collect. That movement didn’t exist when the round started ,it’s created at the point of collection. And I know SME waste firms that operate mostly from the vehicle and add collections mid-run as the norm, not the exception. Those movements can be created somewhere with poor signal — So the offline need looks like it applies to Movement IDs too, not only Transfer IDs, at least for ad-hoc and add-on collections
This branch was never wired into mkdocs nav and has never been deployed/live. The design work has moved to its new canonical home: DEFRA/digital-waste-tracking-api-docs, docs/collections/. Each of the 15 markdown pages here now points to its new equivalent. openapi.yaml, the data/ schemas, and .gitignore are left as-is (out of scope for this pass).
…GitHub Link to the live rendered page (defra.github.io/digital-waste-tracking-api-docs/preview/collections/...) instead of the GitHub blob URL, so anyone following a shared link lands on the actual docs site rather than a raw markdown file on GitHub.
collection-of-waste-getting-started-guide.md
collections-core-concepts.md
collections-error-handling.
api-migration-guide
phase2-phase1-migration-guide
4 participants
No description provided.