Design Discussion — External Ticket Row Providers

[Lars Wireen <lars@…>]

Summary

Design discussion: should TracQuery support external row providers, allowing plugins to contribute ticket-like rows from sources outside the Trac database?

Motivation

As development workflows increasingly span multiple tools — a Trac instance for project management, GitLab for code-related issues, GitHub for open source contributions — developers need a unified view of actionable work regardless of where it is tracked. Today no tool solves this problem in a general, extensible way:

• GitKraken Launchpad and similar tools support a fixed set of known providers (GitHub, GitLab, Jira) but are closed, proprietary and do not support Trac
• Super Productivity supports multiple sources but is a personal task manager, not a configurable query dashboard
• No open source tool provides a unified, queryable dashboard across arbitrary issue trackers including self-hosted ones like Trac

A Trac installation is a natural hub for a developer who uses Trac as their primary tracker and wants to surface issues from other systems alongside their Trac tickets in one prioritised view.

Two Architectural Approaches

Approach A: IQueryRowProvider extension point

TracQuery calls registered providers for rows alongside its own database query. Results are merged, sorted and grouped uniformly.

class IQueryRowProvider(Interface):
    """Extension point for plugins to contribute rows to query results."""

    def get_rows(self, query, constraints):
        """Return iterable of row dicts matching the given constraints.
        
        Each row should contain at minimum: id, summary, status, type.
        Rows from external providers are identified by a provider prefix.
        """

Advantage: seamless integration, external tickets appear in same view. Challenge: field mapping between systems, sort/group consistency, performance.

Approach B: Stable programmatic TracQuery API

A plugin implements its own dashboard page, calling TracQuery programmatically for Trac tickets and external APIs for other sources, then merging and rendering results itself.

Advantage: no changes to TracQuery core, fully self-contained plugin. Challenge: duplicates rendering logic, loses TracQuery UI features.

Questions for Discussion

1. Has Edgewall considered external row providers as TracQuery matures?
2. Is approach A architecturally feasible given TracQuery's current design?
3. Is the programmatic TracQuery API (approach B) stable and documented?
4. Would an IQueryRowProvider interface be welcome as a plugin contribution (cf. #10983, #12156 which follow the same pattern)?

Why This Matters for SQL Report Phase-Out

The stated goal of phasing out SQL reports in favour of TracQuery assumes TracQuery can express everything SQL reports can. External row providers are one capability SQL reports cannot provide either — this would be a genuine improvement over SQL reports, not merely feature parity.

Relation to Existing Tickets

• #10983 — IQueryPreprocessor: translates custom constraints, related pattern
• #12156 — ITicketQueryRenderer: alternate renderers, related pattern
• This ticket asks about the data source layer, orthogonal to both