Latest comment: 11 years ago1 comment1 person in discussion
I've made some modifications to the template sandbox (Template:Tracked/sandbox) that will allow people to track multiple bugs in a table (e.g. User:Technical_13/Bugzilla) by disabling the default float. The way I modified the code shouldn't break any current usage of the template because if the argument doesn't exist, it defaults to the current float. I also thought it looked broken when {{Tracked}} was used without a bug number/argument so I made a modification that allows anyone to click on a link that takes them to bugzilla to create a new bug. I would like to add another link that shows a popup and lets a user add a bug number if one doesn't exist without having to edit the whole page, but I've decided to backburner that part of my idea for now. Does anyone object to the current modifications as they stand? — T13 ( C • M • Click to learn how to view this signature as intended )18:34, 15 March 2013 (UTC)Reply
Why aren't my bugs loading/updating from bugzilla using this template?
There are too many of them, which may cause the Bugzilla server to be flooded with too many JSON requests from a single IP. — Edokter (talk) — 21:56, 17 March 2013 (UTC)Reply
Good catch. I've optimized the code further to save load on parser functions; if you want no floating, simply use |float=none. — Edokter (talk) — 19:07, 20 March 2013 (UTC)Reply
Just learned that the external |[//bugzilla.wikimedia.org/enter_bug.cgi Submit a new bug] could have been a better internal as |[[mediazilla:enter_bug.cgi|Submit a new bug]]
The first situation should not even happen, as this template should never be used without a bug number, so it is a bit pointless. The #if: is there as a fail-safe.
Using parser functions is more expensive on the server-side then using 'unused' CSS. Most CSS should be moved to Common.css anyway. — Edokter (talk) — 19:23, 20 March 2013 (UTC)Reply
Now that the "fail-safe" #if is there in case it is used without a bug number, does it hurt to have the one-click to start submission instead of 3 or 4 clicks and some typing?
The fail-safe prevents any failed requests to the server due to bad use, which should be discouraged. I see no benefit for such a link. — Edokter (talk) — 20:41, 20 March 2013 (UTC)Reply
Done. @Quiddity: If you can update the documentation too that would be great. I can't do it right now as mediawiki.org is loading really slowly for me from this computer (will have to investigate that some more later). — Mr. Stradivarius♪ talk ♪06:41, 2 October 2014 (UTC)Reply
@Edokter: I'm not sure - the only thing I changed was the template. If the template and the gadget are both the same as they were previously, maybe it was something in yesterday's software rollout? (That's yesterday as in Thursday.) — Mr. Stradivarius♪ talk ♪22:07, 2 October 2014 (UTC)Reply
I discovered that the gadget becomes confused if there are duplicate bug numbers, as they appear on the /doc page. So I reinstated the change. Still, the gadget clashes with the 2nd parameter (status). which should have priority? -- [[User:Edokter]] {{talk}}06:30, 3 October 2014 (UTC)Reply
Latest comment: 9 years ago1 comment1 person in discussion
When porting the gadget to Phabricator, I found some areas that could use more efficient HTML markup:
It would be helpful if the actual link to the task had a specific class (the same for all Phabricator tasks). This could be, e.g. 'trakfab'. I believe this is more efficient than searching for a class with a prefix trakfab-T123 (this is actually on the span inside the link), or searching by the title attribute. The class doesn't matter (and there can be additional classes beyond this), as long as it's applied to the link (or the span inside would be okay too) and the same for all tasks.
It would be more efficient to expose the actual number (e.g. 123) as a data attribute. For example, data-phabricator-task="123".
The status <span> (e.g. <span style="color: green; font-weight: bold;text-transform: uppercase;">Resolved</span>) should have a class (e.g. <span class="tracked-status" style="color: green; font-weight: bold;text-transform: uppercase;">Resolved</span>), so it's easier to select for (currently, I'm just using the span at that level, which is fragile). This should be the same for all Phabricator statuses.
Latest comment: 9 years ago7 comments4 people in discussion
The needsinfo state was renamed to stalled in phab:T212 some months ago, I've copied the fixed November 2014 version from c:/d:/m:/mw: to the sandbox here—actually mw: is not more fixed at the moment after an old over new instead of new over old sync. –Be..anyone (talk) 08:05, 17 April 2015 (UTC)Reply
screenshot of bad extra line in Tracked badge in Firefox (Linux) In Firefox on Ubuntu (currently 38 on 15.04, but it's been bad for months), this template looks terrible because the (?) wraps onto a new line as shown. I fixed this in mw.org revision/1416594(make the Phabricator '(?)' help link a small superscript like edit Summary, bump width to 13em so it doesn't wrap to three lines in Firefox) , User:Edokter lost my changes in the next edit with Sync with enwiki. But adding space everywhere to fix one browser isn't ideal. Another fix is simply get rid of the (?) – if someone doesn't know what Phabricator is, the link of "Phabricator" in the template provides a fine explanation. I'll propose and implement this on mw.org -- SPage (WMF) (talk) 00:37, 18 June 2015 (UTC)Reply
Latest comment: 3 years ago6 comments5 people in discussion
The RESOLVED parameter jumps outside of the tracked box and left justifies as can be seen here. Tried "fixed" but that jumped out too as plain text. Ping me back. Cheers! {{u|Checkingfax}} {Talk}06:25, 5 November 2015 (UTC)Reply
@Checkingfax: It's not a bug in the template, but a problem with the way that it's used, that HTML Tidy is making worse. The template is a block-level template, intended for use on a line of its own, as here:
This would normally at the start of a section, just below the heading. However, at Talk:Michael Laucke, it's used inline and inside an indented list:
:*I did some other junk other at Wikidata and the Commons. One thing, at Wikidata I tried to add the Laucke surname but it stalled at Lauck and won't let me remove it. I filed a report with Phabricator. {{tracked|T117527|resolved}}
which produces
I did some other junk other at Wikidata and the Commons. One thing, at Wikidata I tried to add the Laucke surname but it stalled at Lauck and won't let me remove it. I filed a report with Phabricator.
This edit request has been answered. Set the |answered= or |ans= parameter to no to reactivate your request.
@Checkingfax and Redrose64: This issue can actually be resolved, by replacing the line break in the template (before the {{#switch:) with a <br> tag. (I bet you didn't expect anyone to "ping you back" on this after 6 years!) Matma Rextalk01:27, 17 February 2021 (UTC)Reply
Latest comment: 6 years ago1 comment1 person in discussion
Would be nice to have a parameter to output an inline version that did not have the float, box, line breaks, and other formatting décor, but still had the other feature, like resolution of the title of the bug from the bug number. — SMcCandlish☏¢ >ʌⱷ҅ᴥⱷʌ< 11:51, 12 December 2017 (UTC)Reply
Latest comment: 6 years ago1 comment1 person in discussion
It'd be nice to have a param for this, or a paralell template, that communicates that the tracker task in question is "Related" or "See also" or "For reference" rather than being a task that specifically tracks the issue discussed in the relevant thread as "Tracked" does. My first thought is |related=y to change "Tracked" to "Related" in the output, but I'm sure there are other approaches (|heading=arbitrary string etc.). The immediate example that brought this to mind was a talk page discussion for a template that needs changes as a result of a Phab task that has been resolved and deployed. That is, the Phab task is relevant as background or reference to the discussion, but the reverse is not true. --Xover (talk) 10:35, 18 October 2018 (UTC)Reply
You forgot to put T at the beginning. It looks like the template adds 2000 if it receives just a number to convert a Bugzilla ID. Nardog (talk) 20:09, 4 April 2022 (UTC)Reply
Bugzilla was the old tracking system for bug reports and feature requests, its ticket numbers began at 1 in August 2004. Phabricator was brought in later, and its ticket numbers began at T1 in February 2014, and the original series of numbers reached T1391 in November 2014. The two ran in parallel for some time - in late 2014 it was decided to merge the two, so during 21-22 November 2014, all the Bugzilla tasks (whether open or closed) were moved to Phabricator. In order to avoid a clash of numbers. the moved tasks were given new numbers being the old Bugzilla number increased by 2000 and prefixed T. The final Bugzilla ticket, 73681, became T75681 on Phabricator; numbers T75682 up were created directly in Phabricator. A consequence of this is that ticket numbers T1392 through T2000 never existed, and T2001 is about ten years older than T1001. --Redrose64 🌹 (talk) 12:33, 5 April 2022 (UTC)Reply
Done. @Quiddity: If you can update the documentation too that would be great. I can't do it right now as mediawiki.org is loading really slowly for me from this computer (will have to investigate that some more later). — Mr. Stradivarius ♪ talk ♪ 06:41, 2 October 2014 (UTC)
Undone for now; the gadget was inserting the status in all the wrong places. But now my revert causes it not to show up at all! And the gadget hasn't changed. Mr. Stradivarius, what's wrong? 
