[bug]: Work item advanced-search endpoint resolves as identifier route and search param mismatch

[agoodkind]

Current behavior

I’m seeing a reproducible API behavior gap in self-hosted Plane regarding work-item search/list endpoints used by API clients/MCP tools.

• POST /api/v1/workspaces/goodkind-io/work-items/advanced-search/ returns 403 Forbidden with {"detail":"You do not have permission to perform this action."}.
• GET /api/v1/workspaces/goodkind-io/work-items/search/?q=mwan returns 200 with an empty result set.
• GET /api/v1/workspaces/goodkind-io/work-items/search/?search=mwan returns matching issues as expected.

I verified URL resolution and route mapping behavior in the backend and observed that
/api/v1/workspaces/goodkind-io/work-items/advanced-search/ resolves to WorkspaceIssueAPIEndpoint with project_identifier='advanced' and issue_identifier='search', which appears to be a work-item-by-identifier route rather than the expected advanced search/list endpoint.

This causes clients that rely on filtered list paths to fail while unfiltered list calls still work.

• I have searched the existing issues

Steps to reproduce

1. Use a valid API token against a self-hosted Plane workspace (goodkind-io in my reproduction).
2. Confirm authenticated API access works.
3. Call:
   • POST /api/v1/workspaces/goodkind-io/work-items/advanced-search/ with a valid request context.
4. Observe 403 Forbidden and detail: You do not have permission to perform this action.
5. Call:
   • GET /api/v1/workspaces/goodkind-io/work-items/search/?q=mwan
6. Observe 200 with empty list response.
7. Call:
   • GET /api/v1/workspaces/goodkind-io/work-items/search/?search=mwan
8. Observe non-empty results.

Expected behavior

• The advanced-search path should route to a work-item search/list endpoint and return expected filtered results for API clients.
• Search APIs should return consistent behavior and documented query handling for query terms.
• Authenticated users with expected workspace/project access should not receive permission denied for the advanced search endpoint.

Environment

• Environment: Production
• Browser: N/a
• Variant: Self-hosted
• Version: 1.2.3

Additional context

• This is observed while using the upstream Plane API paths and an MCP client.
• get_me-style checks and unfiltered work-item list calls succeed; filtered behavior is where this fails.
• Sanitized evidence can be attached in follow-up if useful.

[agoodkind]

Documentation vs self-hosted behavior

The public API reference documents POST /api/v1/workspaces/{slug}/work-items/advanced-search/ with a JSON body (query, filters, limit, workspace_search, project_id):

• Advanced search work items

The self-hosting guide for OpenSearch-backed advanced search is labeled Pro and references enterprise Helm examples:

• Configure OpenSearch for advanced search

So from a customer perspective it is unclear whether POST .../work-items/advanced-search/ is guaranteed on Community / default self-hosted images, Pro + OpenSearch, or Cloud only. The reproduction here is on self-hosted 1.2.3: the request hits the server, but routing does not match the documented dedicated endpoint (it resolves like a work-item-by-identifier pattern), and GET .../work-items/search/ only honors search= while the official Python SDK sends q= for client.work_items.search(...).

Request

Can you clarify edition parity for:

1. POST .../work-items/advanced-search/ (required on CE? gated by Pro / OpenSearch? Cloud only?)
2. GET .../work-items/search/ query parameter contract (search vs q, backward compatible aliases)

If CE is not intended to implement (1), the API reference and SDK should state that explicitly so MCP and self-hosted users do not assume parity with Cloud.

Related drift reports in the ecosystem: #8542 (MCP/API path sync), makeplane/plane-mcp-server#61 (tools calling non-existent routes). This issue is the narrow, reproducible case for advanced-search routing + search param mismatch against the documented REST contract.