|
|
@@ -235,21 +235,3 @@ Keep `FMS_AUTH_BASE` and `FMS_TOOLS_BASE` as host/base-domain values. Do not inc
|
|
|
```powershell
|
|
|
python -m unittest discover -s tests -p "test_*.py"
|
|
|
```
|
|
|
-## 2026-07-07 query_track direct tracking-number lookup
|
|
|
-
|
|
|
-`query_track` now accepts `order_id`, `order_number`, or `tracking_number`.
|
|
|
-
|
|
|
-- With `order_id`, the backend keeps using `TrackLogic::fmsOrderQueryTrack($orderId)`.
|
|
|
-- With `tracking_number`, or with only `order_number`, the backend calls `TrackLogic::queryTrack($number)` directly. This matches the existing fmsoperate page `admin/Order/trackInfo.html?order_number=xxx`.
|
|
|
-- Python Gateway only forwards the arguments to `/mcp/tools/queryTrack`; it does not resolve orders locally or connect to the business database.
|
|
|
-
|
|
|
-Debug command:
|
|
|
-
|
|
|
-```powershell
|
|
|
-python app.py call --tool query_track --tracking-number 1471904540000000301 --page 1 --limit 20
|
|
|
-```
|
|
|
-## 2026-07-07 query_track timezone alignment
|
|
|
-
|
|
|
-Root cause: the backend page has `session('timezone')` from the normal login session, while MCP tool calls rebuild session data from `mcp_token`. The fmsoperate MCP middleware was reading timezone from `st_user`, but the normal backend session uses the company's timezone (`st_company.timezone_id -> st_timezone.value`). When timezone was empty, `CommonHelper::changeDateByTimeZone($time, 0, '')` returned the original UTC time.
|
|
|
-
|
|
|
-Fix: fmsoperate `McpTokenLogic::checkToken()` now loads the company timezone and returns a normalized `session_context`; `CheckMcpToken` writes `session('timezone')` from that context before calling tool logic. This keeps `query_track` aligned with `admin/Order/trackInfo.html?order_number=xxx`.
|
jackson