Page MenuHomePhabricator

Links to external systems
Closed, WontfixPublic



  • a concise way to quickly enter a link to an item in a frequently used external system without resorting to copy/paste
  • enforcing consistent use of permalinks to refer to items in an external system

It is fairly common in large software projects to want to link to third party bugtrackers, wikis, and other tools. As an example, my "Infrastructure" project may have a Task filed against it that depends on an upstream Task in Phabricator which I want to mention in the summary or a comment. Where such an external system exists in a project, often the need for links is frequent. Many/most of the external systems that you might want to link to will have permalink URL formats that are reasonably constant apart from some short identifier for the item linked. There are a large variation in the systems that might be linked to, and it is unlikely that Phabricator will in future have

Currently I have to enter the full URL, and to prettify it for my readers enter some link text. In some cases, in addition to a lot more typing and cut and paste back and forth between browser tabs, the browser URL bar after a search on the external system may not be a URL for a permalink, but a temporary query string, but for naive users, this is the URL they are most likely to copy and paste. A more concise method of entering a link to a known external system would help to ensure that all links to the external system are permalinks, in addition to making it easier for users to enter the link into remarkup text.

It would be nice if Remarkup could be configured with a list of external systems and URL patterns to automatically generate these links from a shorter link syntax that is easier for the user to enter. I'm thinking something like, except to avoid conflict with existing and future Remarkup, you probably want to use a more defined syntax rather than allowing a regexp to be used for the match.


Remarkup config

   "external_uris": [
        "P" : "{id}",
        "Wiki" : "{id}"

Usage in Remarkup (markup is just an example I think won't conflict with anything already existing, but I haven't put much thought into it)

[(P:T11980)] implements [(Wiki:Links)]

Display in Remarkup:

P:T11980 implements Wiki:Links

Event Timeline

You can do this yourself today with a Remarkup Extension. Parse specific URL patterns in remarkup and return them looking however you want.

Can you please check out Contributing Feature Requests and Describing Root Problems. We don't accept feature requests of this nature unfortunately without understanding the core problem. For example, external systems in the future could be fully integrated automatically with Phabricator, and make the need for special Remarkup pointless. We're not interested in things that are hypothetically cool or useful, and don't have the bandwidth to pursue specialized requests that can already be accomplished with a small plugin.

I updated the summary to hopefully make the problem description more clear, and to add an additional problem which I encountered on one vendor's custom made bug tracker, where their search was returning URLs that were only temporarily valid in the session that the search was done in.

I don't find any documentation for Remarkup Extensions, but I'll look into it, and if I can make something generic enough, I will add it to the Community Contributions page. The hypothetical automatic full integration of external systems sounds a bit like a Pipe Dream, and I won't be holding my breath for that to be implemented. The intention here was to offer an idea for at least a minimal integration that is realistically achievable and applicable to a wide range of external systems that real developers have to deal with on a daily basis.

I looked at T5422, as about 60% of the external systems my upstream vendors use are JIRA so potentially JIRA integration could cover a lot of my use cases, but it is focused more on using JIRA as a primary bugtracker and Phabricator for code review, while our vendors are doing their own review in gerrit, so I am more interested in linking to JIRA tasks as dependencies in Maniphest, and in Phriction, which the current JIRA integration does not cover.

Richer integration would likely happen sooner than something like this, simply because it's something we frequently get asked for and benefits a large group of installs.

Here's a basic remarkup rule:

You can write your own rule and drop it in src/extensions and it should just get picked up. I don't think it will parse already written text, but anything new.

epriestley claimed this task.
epriestley added a subscriber: epriestley.
  • Systems integrated with Doorkeeper (JIRA, Asana, some prototype GitHub support) already get URIs marked up.
  • The current JIRA integration does cover JIRA URIs in all remarkup systems, including Phriction and Maniphest, although you can not link to multiple JIRA installs until T6703, and you must use full URIs (if you use JIRA-123, it's possible that multiple linked installs have project namespaces called "JIRA"). It's possible we'll support this more naturally in the future, but not until after T6703, which is a very low priority.
  • Custom markup rules already supported (see P1157, P1209 for some examples), although you're on your own to write them. These are probably the best fit for your use case.
  • I believe needs for this sort of thing are often very specialized, so I do not currently plan to add any kind of generic, configurable remarkup rule that just matches arbitrary regexps against stuff and links them. You could write such a rule as an extension. One caveat to this is that we currently have bugtraq.url and bugtraq.logregex, which sort of work like this, except in a bad way. I'd like to remove them in the future, but there's an outside possibility that we'll replace them with a more flexible system like the one you describe.

To the degree that this is because a vendor has a custom bug tracker which does not offer permalinks to issues, you should work with your vendor or that vendor's vendor to fix that problem in their system. This is not an issue with Phabricator, and impacts all uses of those URIs (e.g., email, chat, faxes, inscription on stone tablets).