tracking: support explicit carrier_id selection

[HansDaigle]

Summary

• add optional carrier_id to TrackingData for tracking POST APIs
• forward carrier_id in POST /v1/proxy/tracking carrier resolution
• merge carrier_id into TrackingSerializer.create() carrier resolution for POST /v1/trackers

Review updates

• Rebuilt on current karrioapi/karrio:main as a single focused commit.
• Dropped request-body test_mode; test/prod mode remains owned by auth context and X-Karrio-Test.
• Kept manager-view logic lean by moving tracker carrier forwarding into TrackingSerializer.create().

Validation

DJANGO_SETTINGS_MODULE=karrio.server.settings .venv-server/bin/python -m pytest   modules/proxy/karrio/server/proxy/tests/test_tracking.py   modules/manager/karrio/server/manager/tests/test_trackers.py -q

Result: 9 passed, 16 warnings.

[vercel]

@HansDaigle is attempting to deploy a commit to the karrio Team on Vercel.

A member of the Team first needs to authorize it.

[danh91]

Review

The feature direction is right. When a user has multiple connections for the same carrier — two DHL accounts, one domestic and one international — tracking currently has no way to pin to a specific connection at call time. Shipping, pickups, and rates all support carrier_id selection already, so this is a genuine consistency gap and worth closing.

That said, there are two things to address before this can land.

---

Drop test_mode from TrackingData

test_mode is already handled by the API token and auth context. When an API key is scoped to test mode, request.test_mode is set to True, and Connections.first() already reads it:

test_mode = list_filter.get("test_mode") or getattr(context, "test_mode", None)

Adding it to the request body creates a second control surface for the same thing, with ambiguous precedence and a real security implication: the current implementation lets the body value win, which means a production API key with test_mode=True in the payload silently resolves against test-mode carriers. That's backwards. The API token and the X-Karrio-Test header are the right mechanisms — the request body shouldn't override authentication context.

---

Move the carrier_id forwarding into the serializer

For the POST /v1/trackers flow, you've put the forwarding in the view:

if data.get("carrier_id"):
    carrier_filter["carrier_id"] = data["carrier_id"]

But TrackingSerializer already declares carrier_id as a field — it lives in validated_data. The view shouldn't need to know that carrier_id exists and manually forward it; the serializer's own create() should handle it:

carrier_filter = {
    **validated_data["carrier_filter"],
    **(
        {"carrier_id": validated_data["carrier_id"]}
        if validated_data.get("carrier_id")
        else {}
    ),
}

This keeps the view lean and the behaviour self-contained — consistent with how TrackingSerializer already manages its own carrier_filter assembly. The proxy endpoint (/v1/proxy/tracking) is a different case since it calls Shipments.track directly, so view-level forwarding is correct there.

---

Rebase

This branch has diverged heavily from main — the 4000+ file diff is all drift. The manager serializer and proxy view have both changed substantially since this was opened. A rebase before the next push will surface any real conflicts and make the actual change visible.

Once rebased, the functional diff should be small: carrier_id on TrackingData, the forwarding in the proxy view, and the serializer-level merge in TrackingSerializer.create(). That's a clean, focused change with a clear path to merge.

[HansDaigle]

Rebased against current karrioapi/karrio:main and applied the requested review changes: body-level test_mode is removed, carrier_id remains, and manager forwarding now lives in TrackingSerializer.create(). Local verification: affected proxy/manager tracker tests -> 9 passed, 16 warnings.