Issue list view

The issues.view slot adds a view to the switcher above the results on the Issues page and saved filter pages. It is available in the desktop interface at /issues and /issues/<filter_id>. The view name comes from the manifest's title field and appears alongside List, Calendar, and Gantt.

When a user selects the plugin view, the plugin interface occupies the results area. The filter controls remain on the page, so the user can change search criteria while the view is open. The slot is not used on queue or project issue lists.

Configuring the slot

Create a project with weavix create and select the issues.view template. In an existing project, add the slot to slots.tracker in the manifest:

{
  "slots": {
    "tracker": {
      "issues.view": [
        {
          "entrypoint": "index.html",
          "contextLevel": "full",
          "title": {
            "ru": "Мое представление",
            "en": "My view"
          }
        }
      ]
    }
  }
}

This is a manifest fragment: keep the other required fields in your project. Set contextLevel: "full" to receive the current filter. The global issue list has no individual entity ID, so the basic level does not include search criteria.

Slot context

The full slot context has the IssueViewSlotContext type: entityType is issues, and filter contains the criteria currently applied. The context includes unsaved filter changes. savedFilterId may be absent, so a saved filter ID cannot be the only source of search criteria.

The SDK exports the IssueViewSlotContext, IssueViewFilter, and IssueFilterConditions types. The shared ListViewSlotContext<TEntity, TFilter> envelope contains the list type and its typed filter:

type IssueViewSlotContext = ListViewSlotContext<'issues', IssueViewFilter>;

type IssueViewFilter = {
    savedFilterId?: string;
    searchText?: string;
    sort?: { orderBy: string; orderAsc?: boolean };
    groupBy?: string;
    tree?: boolean;
} & (
    | { mode: 'params'; conditions: IssueFilterConditions }
    | { mode: 'query'; query: string; conditions?: IssueFilterConditions }
    | { mode: 'query2'; query: string; conditions?: IssueFilterConditions }
);

IssueFilterConditions maps filter field names to values such as strings, numbers, arrays, or ranges.

The filter.mode field determines the criteria format:

Value	Fields	Meaning
`params`	`conditions` — required object, possibly empty `{}`	Criteria selected in filter controls.
`query`	`query` — QL1 string; `conditions` — optional object	Applied QL1 query. If `conditions` is present, use it together with the query.
`query2`	`query` — QL2 string; the type also permits optional `conditions`	Applied QL2 query. Editor changes that have not been applied are excluded. Tracker currently sends the query text without extra conditions.

The filter object may also contain:

Field	Meaning
`savedFilterId`	Saved filter ID when its page is open.
`searchText`	Text from the separate search field. It is passed without transformation when applied in the current mode. Apply it once alongside that mode's criteria.
`sort.orderBy`	Active sort field. `sort.orderAsc` is included only when the direction is known.
`groupBy`	Grouping field when available for the applied mode.
`tree`	Tree-view flag when available for the applied mode.

For QL2, Tracker sends the applied query string. Sort, grouping, and tree settings from another filter mode are not added to the QL2 context. The context does not contain an array of matching issues: the plugin receives criteria for its own results view.

QL2 and the public API

Do not pass the serialized QL2 expression from filter.query into the public API's query parameter without verifying compatibility. Before fetching issues, check whether the API available to the plugin supports the selected search mode.

Context updates

When the applied filter changes, Tracker sends a context.changed event. The useTrackerPluginContext<'issues.view'>('full') hook receives the new context and updates the component. Use the current filter value when rendering the view, rather than only the value from its first opening.

The selected view is stored in the _view=plugin:<plugin_slug> URL parameter. A link to the view can be opened on the issue list or a saved filter page if the user has access to the plugin.

Other lists

issues.view applies only to the global issue list. The ListViewSlotContext envelope supports distinct filter types for other lists. Project and portfolio views will require their own slots and criteria types; the IssueViewFilter format does not apply to them.

Was the article helpful?

Adding a plugin to the issue creation form picker

Example: Adding a trigger action