In ReportPortal, a stored ticket link carries `btsUrl` and `btsProject` rather than the id of a configured integration. What does that pair resolve to when the server needs the tracker, and why must the integration sit in the `BTS` group?

## The link is text, not a foreign key A stored ticket link in ReportPortal holds `btsUrl`, `btsProject`, `url`, `ticketId` and `pluginName` - five strings. What it does **not** hold is a reference to the integration row that configures the tracker. There is no integration id on the link at all. That is a deliberate choice with consequences in both directions, and understanding it explains most of the surprises people hit when a tracker is moved or reconfigured. ## Resolving the pair When the server actually has to talk to the tracker - to fetch an item's current summary, or to file a new one - it does not follow a pointer. It performs a lookup, using the `btsUrl` and `btsProject` pair as the key: 1. Look for an integration configured **on that project** whose URL and linked project match the pair. 2. Failing that, look among the **global** integrations for the same match. 3. Whichever is found, check that its type belongs to the `BTS` group before using it. That last step is not a formality. `IntegrationGroupEnum` sorts every integration ReportPortal knows about into exactly five groups - `BTS`, `NOTIFICATION`, `AUTH`, `OTHER` and `IMPORT` - and an integration resolved for ticket work is rejected outright if its type sits in any group other than `BTS`. The group is the type system for integrations: it is what stops a mail integration or an authentication provider being handed a request to create a defect just because its URL happened to match. ## What `pluginName` adds `pluginName` records which plugin implementation serves that tracker. It is the optional sixth field on the link, and it is descriptive rather than authoritative - the resolution above goes through the integration, and the plugin follows from the integration's type. Its practical value is on the read side: given a set of links spanning several trackers, `pluginName` tells you which family each one came from without re-resolving anything. ## Why the design, and what it costs | property | consequence | |---|---| | link stores strings, not an id | it survives the integration being deleted or replaced | | link stores strings, not an id | it silently stops resolving when the tracker's URL changes | | `(btsUrl, btsProject)` is the key | two projects on one tracker instance are distinct links | | `BTS` group is checked on resolve | a mis-grouped integration fails at use time, not config time | The single sentence worth remembering is that **a link is durable but inert**. Nothing about the stored strings depends on the integration still existing. Delete the integration and every link keeps rendering exactly as before: the `url` still opens in a browser, `ticketId` still reads correctly, `btsProject` still names a project. Only the operations that need to *reach* the tracker start failing, and they fail at the moment somebody tries one, not at the moment the configuration changed. ## The failure modes this produces - **The tracker moves to a new hostname.** Every previously stored link keeps its old `btsUrl`, so none of them resolve to the new integration any more, while the raw `url` strings may or may not redirect. New links resolve; old ones do not; nothing announces the split. - **A project-scoped integration is added over a global one.** Resolution prefers the project's own, so behaviour for identical links can differ between two projects on the same server. - **An integration is re-created with a different URL spelling.** A trailing slash or an `http`-versus-`https` difference is enough to make the pair stop matching, because the match is on the stored strings. - **A tracker project is renamed.** `btsProject` is part of the key, so the pair no longer resolves, even though the tracker itself is perfectly healthy. ## What to do about it Treat `btsUrl` and `btsProject` as data you own and may need to migrate, not as opaque provenance. If a tracker instance or project is being renamed, the stored links are part of the migration: they are rows carrying the old spelling, and nothing in the server will rewrite them for you. And when you are diagnosing "the tracker button does nothing" on an old failure, check the pair against the configured integrations first - the most common answer is not a broken plugin but a link whose key no longer matches anything in the `BTS` group.