The patch: https://gerrit.wikimedia.org/r/#/c/166283/
The requirements:
* Single ticket URLs to map:
** /bugzilla.wikimedia.org/23223
** /bugzilla.wikimedia.org/show_bug.cgi?id=23223
** /bugs.wikimedia.org/23223
** /bugs.wikimedia.org/show_bug.cgi?id=23223
* https://bugzilla.wikimedia.org/index.cgi should go to https://phabricator.wikimedia.org/
* https://bugzilla.wikimedia.org/query.cgi should go to https://phabricator.wikimedia.org/maniphest/query/
* https://bugzilla.wikimedia.org/reports.cgi and https://bugzilla.wikimedia.org/report.cgi and https://bugzilla.wikimedia.org/chart.cgi should all go to https://phabricator.wikimedia.org/maniphest/report/
* https://bugzilla.wikimedia.org/describecomponents.cgi should go to http://phabricator.wikimedia.org/project/query/all/
* Attachment URLs like https://bugzilla.wikimedia.org/attachment.cgi?id=12345 will be ignored. Rather uncommon plus we won't keep the numbering scheme. Still possible to query for the attachment ID manually in Phabricator though.
* https://bugzilla.wikimedia.org/buglist.cgi can have dozens of URL parameters, and can have hundreds of parameters. Using buglist.cgi with a bug_id parameter plus a number of bug IDs with commata inbetween (to get a static list of tickets listed) probably isn't too common. Queries for a specific status (open tickets) in some specific products/components are probably more likely, but I don't consider it doable to have a mapping between Bugzilla products and components and Phab projects somewhere publicly stored, which could be accessed to "on-the-fly" turn that unlimited number of potential URL parameters into some query that more (or rather less) would even show similar results in Phabricator. The way search results (and their URLs) are created are just too different. Proposing WONTFIX for this part (though I'd be really happy to be proven wrong). This also applies to Bugzilla's "saved searches" functionality as it also ends up on buglist.cgi