mirror of
https://github.com/Hestia-Homes/Model.git
synced 2026-07-12 13:29:04 +00:00
uploaded_files has no property_id — matching is on landlord_property_id — so the property_ids path was pointless indirection (look property.id up in property just to translate back to landlord_property_id). The FE holds landlord_property_id per row anyway. task.inputs hand-pick key is now landlord_property_ids: str[] (was property_ids: int[]). resolve_selection unions two landlord_property_id sources — project_codes expanded via hubspot_deal_data, and the hand-picked ids taken as given — and no longer queries the property table at all. Trigger-only change; the domain plan, orchestrator and matching already work in landlord_property_id. ADR-0060, CONTEXT.md and the request schema updated to match. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
21 lines
923 B
Python
21 lines
923 B
Python
from uuid import UUID
|
|
|
|
from pydantic import BaseModel
|
|
|
|
|
|
class BulkDownloadRequest(BaseModel):
|
|
"""A request to assemble a Download Package (ADR-0060).
|
|
|
|
The front end creates the app-owned Task first and writes the **selection
|
|
config** into ``task.inputs`` (a JSON object of
|
|
``{project_codes?: str[], landlord_property_ids?: str[], portfolio_id?: int}``
|
|
— so a large selection never travels in an HTTP body), then passes only the
|
|
``task_id`` here. The backend reads the selection from ``task.inputs`` and
|
|
resolves it to the distinct ``landlord_property_id`` set (the key
|
|
``uploaded_files`` is matched on): the union of every property in the named
|
|
HubSpot ``project_codes`` (from ``hubspot_deal_data``) and the hand-picked
|
|
``landlord_property_ids``. At least one of the two must be given;
|
|
``portfolio_id`` is optional and used only to name the package.
|
|
"""
|
|
|
|
task_id: UUID
|