Template talk:Tracked

Latest comment: 2 years ago by Redrose64 in topic +2 issue

{{{float|}}} argument and "Submit new bug"

edit

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?

edit

I have the check-box checked in my user settings to update my {{Tracked}} bugs, but I don't see any updating going on on my page. Can anyone help me figure this out? T13   ( C • M • Click to learn how to view this signature as intended ) 19:35, 17 March 2013 (UTC)Reply

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
Where can I find the documentation for bugzilla's api so I can see if I can find a work-around for it? T13   ( C • M • Click to learn how to view this signature as intended ) 22:13, 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
Notes:
User:Technical 13   ( C • M • Click to learn how to view this signature as intended ) 19:09, 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]]
User:Technical 13   ( C • M • Click to learn how to view this signature as intended ) 19:18, 20 March 2013 (UTC)Reply
  1. 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.
  2. 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
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
Can the sandbox template code be moved in replace the current code as-is now? It would be an improvement on what is there. User:Technical 13   ( C • M • Click to learn how to view this signature as intended ) 21:07, 20 March 2013 (UTC)Reply

Adapting this template to Phabricator

edit

Hi, we are planning to deprecate Bugzilla (and a bunch of other tools) in favor of mw:Phabricator. We are looking for volunteers to adapt this template at Port {{tracked}} gadget to query Phabricator API. Any takers?--Qgil (talk) 19:32, 13 May 2014 (UTC)Reply

Is there any API documentation? Edokter (talk) — 21:40, 13 May 2014 (UTC)Reply
See Conduit API.--Qgil (talk) 16:55, 14 May 2014 (UTC)Reply

Please copy the code from Template:Tracked/sandbox to Template:Tracked. It's been in use at mediawiki for the last 3 weeks without problem. Also I checked with @He7d3r: in IRC, who confirmed it is still good to go. Thanks. Quiddity (talk) 02:43, 2 October 2014 (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
  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? -- [[User:Edokter]] {{talk}} 18:12, 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
The gadget is still under discussion at MediaWiki_talk:Gadget-BugStatusUpdate.js#Adapting_this_gadget_to_Phabricator (and now phab:T539)
I've updated the docs, but I notice that it needs the pipe added. (Someone else had tweaked the sandbox, just prior). HTH. Quiddity (talk) 23:01, 3 October 2014 (UTC)Reply
I've written an update of the gadget (to use Phabricator instead) and proposed it to be deployed. See MediaWiki_talk:Gadget-BugStatusUpdate.js#Adapting_this_gadget_to_Phabricator. Mattflaschen (WMF) (talk) 05:55, 10 February 2015 (UTC)Reply
Thanks. I updated the gadget. -- [[User:Edokter]] {{talk}} 10:13, 10 February 2015 (UTC)Reply

Proposed style change - removing the gradient

edit

At WP:VPI#Bugtrack template, there's a proposal to change this template's styling, to remove the gradient and replace it with a flat grey. Please weigh in, there. Thanks. Quiddity (talk) 22:37, 14 September 2014 (UTC)Reply

Making information easier to extract from JavaScript

edit

When porting the gadget to Phabricator, I found some areas that could use more efficient HTML markup:

  1. 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.
  2. It would be more efficient to expose the actual number (e.g. 123) as a data attribute. For example, data-phabricator-task="123".
  3. 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.

I'd be glad to clarify any of this if you ping me or ask on IRC. Mattflaschen (WMF) (talk) 05:49, 10 February 2015 (UTC)Reply

Stalled

edit

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

Done. -- [[User:Edokter]] {{talk}} 08:53, 17 April 2015 (UTC)Reply
Allegedly 12em breaks Firefox, see mw: version history. –Be..anyone (talk) 09:32, 17 April 2015 (UTC)Reply
I see no difference in Firefox; probably a custom font. -- [[User:Edokter]] {{talk}} 10:54, 17 April 2015 (UTC)Reply
12em where breaks Firefox? Version history of what at mw:? --Redrose64 (talk) 11:25, 17 April 2015 (UTC)Reply
mw:Template:Tracked, what else? I can't judge it, both versions work(ed) for me. –Be..anyone (talk) 11:41, 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

RESOLVED parameter has a bug

edit

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.
The proper fix is to move {{tracked}} to the top of the section, but if you need an inline link to the phabricator ticket, write it as [[phab:T117527]] which produces phab:T117527. --Redrose64 (talk) 14:33, 5 November 2015 (UTC)Reply

@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 Rex talk 01:27, 17 February 2021 (UTC)Reply

Code added to sandbox and seems to work on Template:Tracked/testcases#Inline use — Martin (MSGJ · talk) 15:35, 17 February 2021 (UTC)Reply

Thank you! {{u|Checkingfax}} {Talk} 18:13, 18 February 2021 (UTC)Reply

  Donexaosflux Talk 16:11, 19 February 2021 (UTC)Reply

Inline version

edit

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

Alternate version for "related" tracker item

edit

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

+2 issue

edit

See 1081015474: I entered {{tracked|305333}} (see the source), but the result links to 307333, not to 305333. Why? --NGC 54 (talk | contribs) 19:59, 4 April 2022 (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