GithubHelp home page GithubHelp logo

mozilla / mediawiki-bugzilla Goto Github PK

View Code? Open in Web Editor NEW
54.0 39.0 39.0 1.38 MB

A MediaWiki extension that provides read-only access to the Bugzilla REST API

License: Mozilla Public License 2.0

PHP 96.06% CSS 2.94% Smarty 0.97% Makefile 0.04%

mediawiki-bugzilla's Introduction

MediaWiki extension for Bugzilla

This is a MediaWiki extension that provides read-only access to the Bugzilla REST API

Please note that there are still big outstanding bugs!

Requirements

  • MediaWiki 1.17 or above.
  • For charting, requires gd

Installation

These directions assume your MediaWiki installation is at /var/lib/mediawiki. Please substitute your installation path if it is different

  1. Install the requirements above
  2. Check the project out into /path/to/your/mediawiki/extensions/Bugzilla
  3. Edit /path/to/your/mediawiki/LocalSettings.php and add require_once("$IP/extensions/Bugzilla/Bugzilla.php"); and change/override any configuration variables. Current configuration variables and their defaults can be found at the end of Bugzilla.php

Usage

You use this extension in this way:

<bugzilla>
    (JSON REST API query key/value pairs)
</bugzilla>

By default, it will output a colored table:

Example output

Note that the wiki tag name defaults to "bugzilla" but is configurable by the administrator.

Options

Valid bugzilla tag options are:

  • type: "bug" or "count" (defaults to bug)
  • For type bug:
    • display: "table" or "list" or "count" (defaults to table)
  • For type count:
    • display: "bar" or "pie"
    • size: "small", medium" or "large" (defaults to large)
  • stats: "show" or "hide" (defaults to "show")

Examples

All P1 bugs in the Bugzilla product:

<bugzilla>
    {
        "product": "Bugzilla",
        "priority":"P1"
    }
</bugzilla>

All new bugs flagged as uiwanted in the whiteboard:

<bugzilla>
	{
	    "whiteboard": "uiwanted",
	    "status": "NEW"
    }
</bugzilla>

All bugs in the bugzilla.org component that were resolved in 2011, with the stats summary hidden:

<bugzilla stats="hide">
    {
        "component": "bugzilla.org",
        "changed_after": "2011-01-01",
        "changed_before": "2011-12-31",
        "changed_field": "status",
        "changed_field_to": "resolved"
    }
</bugzilla>

Some commonly used query parameters are:

  • id
  • component
  • product
  • status
  • resolution
  • keywords
  • whiteboard
  • target_milestone
  • version
  • changed_after
  • changed_before

For more details on how to query in various ways, see the documentation for the Bugzilla REST API

Configurable fields/columns

Specify fields in the "include_fields" setting of BZ REST API options as you normally would. Mediawiki-bugzilla will then a) only fetch those fields and b) display those columns.

<bugzilla>
{
    "whiteboard": "[mediawiki-bugzilla]",
    "include_fields": ["id", "summary", "whiteboard", "status", "resolution"]
}
</bugzilla>

Screenshot of the above

Charting

There is also some support for charting:

<bugzilla type="count" display="bar">
    {
        "whiteboard": "[snappy:p1]",
        "x_axis_field": "status"
    }
</bugzilla>

Screenshot of the above:

Screenshot of the above

<bugzilla type="count" display="pie">
{
    "whiteboard": "[mediawiki-bugzilla]",
    "x_axis_field": "status"
}
</bugzilla>
<bugzilla type="count" display="pie" size="medium">
{
    "whiteboard": "[mediawiki-bugzilla]",
    "x_axis_field": "status"
}
</bugzilla>
<bugzilla type="count" display="pie" size="small">
{
    "whiteboard": "[mediawiki-bugzilla]",
    "x_axis_field": "status"
}
</bugzilla>

Screenshot of the above:

Screenshot of the above

Limitations

  • This extension (by design) is read-only
  • This extension currently queries as a public (not logged in) user
  • Charts are fairly hardcoded and don't work in many cases

Known Issues

mediawiki-bugzilla's People

Contributors

adngdb avatar brandonsavage avatar cargan avatar cass-moz avatar christi3k avatar darchons avatar dennisroczek avatar dylanwh avatar edmorley avatar flipez avatar globau avatar hexmode avatar kwierso avatar lauraxt avatar legneato avatar lmandel avatar lonnen avatar pablofiumara avatar rdalverny avatar reedy avatar rhelmer avatar selenamarie avatar superawesome avatar ziegeer avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

mediawiki-bugzilla's Issues

Table layout has become totally misaligned recently

I've been on PTO for a week and when I came back all my Bugzilla tables were broken. It appears as if the table is left-aligned to the middle of the page. As a result some of the columns are off the page.

You can see an example here:
https://wiki.mozilla.org/Releases/Firefox_31/Test_Plan#Iteration_31C-30A-29B.3

You can see a screenshot here:
https://ashughes.com/?attachment_id=165

I'm not sure if a new version of Mediawiki was pushed to wiki.mozilla.org and broke this so I'm reporting it here for now. Feel free to close if this should go somewhere else.

Colon in Component Name

We have an internal Wiki we just added the Bugzilla extension to, and it works pretty well! One thing I haven't been able to figure out yet, however, is how to reference some of our components that contain colons. When I do, the following error message appears:

Warnings were generated during the execution of function
String Department: Team is invalid using regex /^[\w,@\.\s\*\/%!()+-]*$/

I have also tried using "%3A" instead of ":"; however no results are ever returned.

Sometimes throws a divide by zero in php

I only noticed this because of New Relic:

https://rpm.newrelic.com/accounts/263620/applications/2207193/traced_errors/1567128315

https://wiki.mozilla.org/Features/Release_Tracking

I'm guessing it happens when a particular search result returns zero bugs. That page happens to have many uses of this extension, so it's more prone to this than most pages would be.

in unknown called at /data/www/wiki.mozilla.org/wiki/extensions/Bugzilla/templates/bug/table.tpl (69)
…t /data/www/wiki.mozilla.org/wiki/extensions/Bugzilla/
BugzillaOutput.class.php (55)
…der called at /data/www/wiki.mozilla.org/wiki/extensions/Bugzilla/
Bugzilla.php (163)
in BugzillaRender called at ? (?)
…unc_array called at /data/www/wiki.mozilla.org/wiki/includes/parser/
Parser.php (3744)
…called at /data/www/wiki.mozilla.org/wiki/includes/parser/
Preprocessor_DOM.php (1110)
…M::expand called at /data/www/wiki.mozilla.org/wiki/includes/parser/
Parser.php (2986)
…Variables called at /data/www/wiki.mozilla.org/wiki/includes/parser/
Parser.php (1099)
…rnalParse called at /data/www/wiki.mozilla.org/wiki/includes/parser/
Parser.php (345)
… Parser::parse called at /data/www/wiki.mozilla.org/wiki/includes/
WikiPage.php (2914)
…iew::doWork called at /data/www/wiki.mozilla.org/wiki/includes/
PoolCounter.php (187)
…erWork::execute called at /data/www/wiki.mozilla.org/wiki/includes/
Article.php (587)
…view called at /data/www/wiki.mozilla.org/wiki/includes/actions/
ViewAction.php (40)
in ViewAction::show called at /data/www/wiki.mozilla.org/wiki/includes/Wiki.php (484)
…iki::performAction called at /data/www/wiki.mozilla.org/wiki/includes/
Wiki.php (278)
…ki::performRequest called at /data/www/wiki.mozilla.org/wiki/includes/
Wiki.php (593)
in MediaWiki::main called at /data/www/wiki.mozilla.org/wiki/includes/Wiki.php (503)
in MediaWiki::run called at /data/www/wiki.mozilla.org/wiki/index.php (58)

Add support for ordering.

I'd like to show "10 most recently fixed bugs" in a wiki page. No matter how I query bugzilla, the result is always returned ordered by id ascending. Thus I can't control the initial display order, and it shows the lowest numbered bugs first.

I can approximate the results by querying for "status changed to resolved in last 2 weeks", but the results are still initially displayed in bug id order - I can't "pre select" "descending date".

Add an option to hide the display of the bug statistics.

In table view, we would show but statistics as follows,
1 Total; 0 Open (0%); 1 Resolved (100%); 0 Verified (0%);

However, sometimes we just want to give a list of bugs without this statistic info, so it would be better to add an option to hide it.

Add more committers?

It looks like @brandonsavage might not be at Mozilla anymore. Can we get more committers? There looks to be some good pull requests.

I would be happy to be a committer and help maintain again 😄

BugzillaJSONRPCQuery class doesn't exist

If you set your $wgBugzillaMethod to json-rpc it tries to use a non existent BugzillaJSONRPCQuery class

FATAL

Fatal error: Class 'BugzillaJSONRPCQuery' not found in /var/www/wiki/mediawiki/core/extensions/mediawiki-bugzilla/BugzillaQuery.class.php on line 13

Add more example queries to readme

When creating some of the queries for the Treeherder wiki page, it took a bit of experimentation to get the params correct. This is partly due to having to convert from the API docs, and partly due to the Bugzilla REST API docs being unhelpful.

Either way, let's add some more examples to show how to:

  • Exclude multiple bugs from the results, either by direct ID or because they block another bug
  • Sort by multiple criteria

eg:
https://wiki.mozilla.org/Auto-tools/Projects/Treeherder#All_others

All other open bugs not included above.
<bugzilla>
{
"component": "Treeherder",
"resolution": "---",
"id": "1030636,1059400,1072676,1072681,1054977,1080757", "id_mode": "exclude",
"blocked": "1030636 1059400,1072676,1072681,1054977,1080757", "blocked_type": "not_contains_any_words",
"include_fields": "id, priority, summary, assigned_to",
"order": "priority,assigned_to"
}
</bugzilla>

Hardcoding paths to resources

Already on my TODO list, but it annoyed me even more today.

Considering this repo is called mediawki-bugzilla, and as such git would clone it to a folder called mediawiki-bugzilla by default upon checking out https://github.com/mozilla/mediawiki-bugzilla.git - though the readme does differ:

  1. Check the project out into /var/lib/mediawiki/extensions/Bugzilla
  2. Edit /etc/mediawiki/LocalSettings.php and add
    require_once("/var/lib/mediawiki/extensions/Bugzilla/Bugzilla.php");

^ Should be using $IP/extensions/Bugzilla/Bugzilla.php

But then we really really hard code it:

$out->addScriptFile("$wgScriptPath/extensions/Bugzilla/web/jquery/1.6.2/jquery.min.js");

CODE_OF_CONDUCT.md file missing

As of January 1 2019, Mozilla requires that all GitHub projects include this CODE_OF_CONDUCT.md file in the project root. The file has two parts:

  1. Required Text - All text under the headings Community Participation Guidelines and How to Report, are required, and should not be altered.
  2. Optional Text - The Project Specific Etiquette heading provides a space to speak more specifically about ways people can work effectively and inclusively together. Some examples of those can be found on the Firefox Debugger project, and Common Voice. (The optional part is commented out in the raw template file, and will not be visible until you modify and uncomment that part.)

If you have any questions about this file, or Code of Conduct policies and procedures, please reach out to [email protected].

(Message COC001)

Order table by data in whiteboard

Would you please tell me how to get order (sort) to work in the following table?

<bugzilla>
    {
        "component":"Common CA Database",
        "status":["UNCONFIRMED", "NEW", "ASSIGNED", "REOPENED"], 
        "whiteboard":"ccadb-roadmap",
        "cf_blocking_b2g_type":"contains",
        "include_fields": ["id", "summary", "status", "whiteboard", "assigned_to", "last_change_time"],
        "order": "whiteboard"
    }
</bugzilla>

Problems specifying $FIELDNAME_type

Using XML-RPC, I'm able to write a query:

<bugzilla>
    {
        "whiteboard": "EasyHack",
        "status": "NEW"
    }
</bugzilla>

but unable to get a result when I introduce a $FIELDNAME_type parameter:

e.g. status_whiteboard_type=allwords&status_whiteboard=EasyHack&bug_status=NEW...

<bugzilla>
    {
        "whiteboard": "EasyHack",
        "whiteboard_type": "contains_all_words",
        "status": "NEW"
    }
</bugzilla>

Am I using the correct syntax here?

Thanks

Page save/load never ending when badly configured

Changing the config from the mozilla repo to the WMF one (I think the rest url is wrong. changing $wgBugzillaMethod from REST works quickly), page load/page save seems to take for ever.

I'm guessing it's timeout related

MediaWiki backwards compatibility

How much do you care about it? I don't tend to go out of my way to break it, but when we've got really old code laying around it annoys me.

We're obviously using master, and Mozilla is using 1.19. "Legacy" release, but modern enough.

There are 2 main areas here; the updater code (pretty simple, might aswell dump the pre 1.16 code) and then JS/CSS code.

MediaWiki ships with jQuery, jQueryUI and numerous other plugins. So extensions don't need to keep their own versions around in most case, and even more so, not a normal version and a minified one. And dependencies, minification and other niceties.

Specifically in this case means BugzillaIncludeHTML needs updating.Then rather including files directly through addStyle/addScript, we add Resource Loader Modules

Provide a Working Example/Test Page

It would help users, if you could provide a working test page with a good set of examples.
This should include the extension related configuration, so users can reproduce results.

Switch to BzAPI-compatibility endpoint

BzAPI will be decommissioned at some point in the near future, so this extension should be migrated to use BMO's native BzAPI-compatibility layer.

With regards to this plugin, the compatibility layer should function exactly like BzAPI, but to be extra careful, we could add an option to plugin's JSON to specify the endpoint, so we can test it on individual tables first.

Set a formal code style

Using phpcs would help ensure we have a consistent style in the repository, and in PRs as well.

In the current state, I'm not so sure: checking current code style against any of below rulesets returns some significant changes.

I can set this up in a PR, but choosing the standard is the crux.

order parameter isn't honoured (jquery datatable shouldn't reorder the table rows)

if you provide an order parameter to a table, this isn't honoured in the table; it's always sorted by ID.

eg.

<bugzilla>
{
"keywords": "bmo-big bmo-goal",
"keywords_type": "anywords",
"priority": ["P1","P2","P3","P4","P5"],
"include_fields": "id, priority, summary, status, resolution, assigned_to, keywords",
"order": "keywords DESC, priority, bug_id"
}
</bugzilla>

the results are returned by bugzilla, and inserted into html in the correct order by the php plugin. they are then re-ordered by the jquery datatable, which i consider to be a bug.

as far as i can tell this can be fixed by setting aaSorting to an empty array when initialising dataTable.

Bug tables should have configurable pagination

This seems to have changed recently, but we're not sure how.

Our bug tables are showing ten bugs by default. We'd like to be able to specify more ("iDisplayLength" seems to be the Datatable setting). We can't hack this into the page because wiki.mo doesn't allow embedded JS.

Can we get a "pagelength" config param for each <bugzilla> tag, please?

Link to the Bugzilla query in the table or chart

For the table view, It is often useful to be able to click through to see the query on Bugzilla. Right now I have no way to do this other than figuring out what I think the query should be, and pasting it into the wiki page by hand above or below the mediawiki-bugzilla generated table.

It would be super useful if the table generated by mw-bz also generated a link to the entire query that it just constructed. The link could be in the table header or just in some text above or below the other information displayed. It may nice most useful to put it into a row above the listed bugs with the anchor text "Full Query". (Rather than just displaying a giant messy bugzilla url.)

"[email protected]" not handled the same as "nobody"

For certain components, the default assignee is not [email protected]
This means that for bug tables that include an assignee column, the assignee is displayed as "server-ops-webops" rather than "" (like the other nobody bugs do).

Perhaps we should just treat *@mozilla.bugs as nobody, here:

// Special case for "nobody"

 // Special case for "nobody"
if( isset($data['name']) && (empty($data['name']) || $data['name'] == 'nobody') ) {
    $out = '';
}

Add an option to get a count without displaying a chart

I have a lot of places in WMO where I want to display a total number of bugs, but don't want a graphic or a chart at all. Just a number. Pretty sure I'm not the only one who updates numbers painfully by hand!

Could there be an option for type="count" where we just suppress the chart? Or is there some simple way to do this that I'm missing? Thanks!

Can't get 'bar' or 'pie' chart to work.

At https://jogamp.org/wiki/index.php/SW_Tracking_Report_Feature_Objectives_Overview
we have used your generally working extension now.

Yes, we have created the '$wgBugzillaChartStorage' 'charts' folder w/ proper permissions for the apache2 server.

However, if trying to get charts working, bar or pie, we either get the error:

" Bugzilla query error
Notice: Array to string conversion in /srv/www/jogamp.org/mediawiki-git-1.32/extensions/Bugzilla/templates/error.tpl on line 5 error, http-bad-status, Array"

or the resulting images are corrupt / buggy.

+++

Our test page: https://jogamp.org/wiki/index.php/Test01

== bar 1 ==

{
"version": "2.4.0",
"x_axis_field": "status"
}

== bar 2 ==

{
"version": "2.4.0",
"y_axis_field":"percent_complete",
"x_axis_field": "status"
}

== pie 1 ==

{
"version": "2.4.0",
"x_axis_field": "status"
}

== pie 2 ==

{
"version": "2.4.0",
"y_axis_field":"percent_complete",
"x_axis_field": "status"
}

Software uses soon-to-disappear BzAPI endpoint

https://github.com/mozilla/mediawiki-bugzilla/blob/master/Bugzilla.php#L176

Here's the boilerplate message:

Hi,

You are receiving this email because a service or services you are
believed to own or control is/are making requests of "BzAPI", the
Bugzilla API proxy server at https://api-dev.bugzilla.mozilla.org/.

This service is due to be decommissioned. Fortunately, Bugzilla has a
new native REST API which works somewhat similarly that you could use
instead:
https://wiki.mozilla.org/Bugzilla:REST_API

Moving to that new API would require some porting work. If that seems
like too much effort, fear not, because there is also a BzAPI
compatibility layer built on top of the new API. Because it's
compatible, using that should simply require a change of API endpoint.

Change:
https://api-dev.bugzilla.mozilla.org/latest/
(or https://api-dev.bugzilla.mozilla.org/1.3/)
to
https://bugzilla.mozilla.org/bzapi/

You should not expect the api-dev server to continue to work after
Friday 14th November. So please test and migrate your production
instance(s) over before then, either to the BzAPI compatibility endpoint
or to the new native REST API.

Thanks for using BzAPI. It's been a great ride :-)

Gerv

Display item count when fields of type array (eg attachments) are specified in include_fields

For this markup:

<bugzilla>
{
"component": "Treeherder",
"resolution": "FIXED",
"include_fields": "id, priority, summary, attachments, assigned_to",
"order": "priority"
}
</bugzilla>

The resultant bug table includes an "attachments" column, however it contains things like:

"Array, Array, Array"
""
"Array"
"Array, Array"

This also presumably affects any of the other array fields listed on https://wiki.mozilla.org/Bugzilla:BzAPI:Objects#Bug (ie: cc, comments, flags, groups, ...).

We should convert this to a count of array items (ie number of attachments in the example above) and optionally allow the field to instead enumerate the values (eg list the flag names or emails addresses for 'flags' or 'cc').

screenshot

About Version

"
Google LLC
Copyright 2023 Google LLC. All rights reserved.
Google Chrome 117.0.5938.153 (Official Build) (32-bit)
Revision 588c66dfb93af8aa3bb790479b69bb79e1bf194a-refs/branch-heads/5938@{#1548}
OS Android 12; SKY Pad10 Build/SP1A.210812.016; 31; REL
APK versionCode 593815331
APK targetSdkVersion 34
isAtLeastU/targetsAtLeastU false/true
Google Play services SDK=233300000; Installed=233717044; Access=1p
JavaScript V8 11.7.439.21
User Agent Mozilla/5.0 (Linux; Android 10; K) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/117.0.0.0 Safari/537.36
Command Line --top-controls-show-threshold=0.27 --top-controls-hide-threshold=0.17 --enable-viewport --validate-input-event-stream --enable-longpress-drag-selection --touch-selection-strategy=direction --disable-composited-antialiasing --enable-dom-distiller --flag-switches-begin --flag-switches-end --origin-trial-disabled-features=WebGPU --disable-nacl
Executable Path No such file or directory
Profile Path /data/user/0/com.android.chrome/app_chrome/Default
Active Variations 18d548b8-ca7d8d80
d9d79f6b-ca7d8d80
df32e99d-c0a8ddbd
b6aa8178-ca7d8d80
78ce0fb-377be55a
17eb91eb-ca7d8d80
27e53b84-377be55a
6a78723c-377be55a
4f43fcab-7d05a30a
4b681c8b-f611d61c
6407ded2-377be55a
932a3958-33c3eba5
73440212-377be55a
25a516b9-377be55a
cbfd06b9-ca7d8d80
6ae4701-ca7d8d80
8c693aa5-ca7d8d80
3efb9579-377be55a
3dd63e02-ca7d8d80
a8066858-ca7d8d80
60929057-377be55a
b05e1e6c-ca7d8d80
aa21b4f1-377be55a
9dca89f8-377be55a
5f8ff765-d6f282a8
eddd0d82-107edff7
df41299a-1f8c5973
c23b87b6-b7a0c4b5
aba1243e-ca7d8d80
a84012f2-377be55a
b6cffda3-ca7d8d80
a2ff3364-ca7d8d80
3095aa95-3f4a17df
42cf67ed-377be55a
9338e1c5-5c1f227c
89f2e43d-377be55a
d2e8e6e4-377be55a
42988c47-ca7d8d80
c9bd3ea5-3cd4d4d9
4555086c-ca7d8d80
7d41a07a-377be55a
b4fb8450-ca7d8d80
d9a54c17-a36d0283
4b14b0bc-377be55a
250dda8b-cd5781de
28329b37-377be55a
c3f415b4-377be55a
1e940a7c-ca7d8d80
41e765a5-ab02a1cf
55380672-ca7d8d80
1b01c3a3-ca7d8d80
d555098c-dd8fab8c
e5249c82-ca7d8d80
24e1e5d7-377be55a
81b1a2c3-377be55a
4aebab6e-377be55a
b2cff759-ca7d8d80
a582a1b8-5ad3f43d
a5b9261b-219af806
948b1b97-71b516e3
807a770a-6ec7f40e
e26879f8-ca7d8d80
d92d97b4-ca7d8d80
55e87fa-ca7d8d80
d97f772b-12ede6a2
87a22c16-2abeac9a
4e0c30d2-377be55a
5f0e39d2-377be55a
a11acca5-33c3eba5
62c71f3-6b922b43
1d865dc8-b902abc9
e3ecb0dd-377be55a
3fd33f16-ca7d8d80
54bad6d9-f9a43703
1c85759e-3e4f4ae5
3a4ffe07-ca7d8d80
6b9250af-f9a43703
c272f203-12ede6a2
6d27df64-9f7f68d9
266af18d-ca7d8d80
6fea66b3-ca7d8d80
abf5aad6-5bd15e37
b4d9badf-40e2b871
8835ae81-e6e520d9
906834f5-9da5e2a0
829fa6ed-377be55a
f782a8be-377be55a
71c14987-ca7d8d80
b27b7146-ca7d8d80
f7587c0d-377be55a
5e3a236d-4113a79e
8659ca17-377be55a
bd60f05-377be55a
1ac61599-28ad44a
1e0a475c-33c3eba5
3857eaa7-33385eeb
6e27f578-ca7d8d80
f7b9a9e3-ca7d8d80
4b82c9ff-ca7d8d80
c88fa1e2-ee63ae02
8500acb0-73d9728a
75ffb03a-377be55a
ca5a2953-ca7d8d80
3781483a-377be55a
d626966e-ca7d8d80
da493d3c-ca7d8d80
10ce7fc1-377be55a
ca12356a-377be55a
62e82091-4113a79e
5d1017fe-ca7d8d80
15ccc4bd-af6e0697
d55357c-f8c48e31
59a12fbe-67ede164
365085fd-f9a43703
4bedb5b0-377be55a
45a2f2f-9b948476
28410024-377be55a
137f6fe-c3e0075
9a382556-377be55a
4ea303a6-ecbb250e
3b1e7062-ca7d8d80
78506c55-ca7d8d80
c5dfd685-ca7d8d80
a83da733-377be55a
7c0d937f-ca7d8d80
5eb745a8-ca7d8d80
30cf4980-ca7d8d80
19e446cd-ca7d8d80
d7d493f4-ca7d8d80
f2b08819-ca7d8d80
5466b624-ca7d8d80
1edcddf4-f726f89c
5a3e6371-377be55a
fd4b313c-873cd3a5
8a38784f-377be55a
9af490f6-12f45162
3f2823d1-1ec56b91
f82ee03-ea8328
911a4c15-ca7d8d80
4a08d55f-ca7d8d80
7f19e54-ca7d8d80
d0083347-ca7d8d80
850b877c-33c3eba5
788db06c-8035bf4c
88eaebde-ca7d8d80
b46f46d-377be55a
f43e9210-ca7d8d80
7b1d6dc2-ca7d8d80
e5ade537-377be55a
f41074f2-2eda6922
7e16aa75-ca7d8d80
494d8760-52325d43
bc93991a-f08f240b
7b2873c2-5c691220
3ac60855-486e2a9c
f48c01d3-1f0847de
63dcb6a3-1185807e
e706e746-18d1395b
f296190c-19721340
4442aae2-6bdfffe7
f690cf64-7158671e
ed1d377-e1cc0f14
75f0f0a0-e1cc0f14
710c3f90-4ad60575
e2b18481-4c073154
e7e71889-4ad60575
3a8271ac-e9e131c
858aa29b-ca7d8d80
ec21b181-377be55a
857d3571-9f7f68d9
c1e0d32e-377be55a
38639f6a-377be55a
216c8a00-377be55a
37d8197a-377be55a
6d5ed605-ca7d8d80
450afa61-4ed7d93
e53e8ff0-4f8fa018
514700c0-b2cf01c6
657f1834-17a8ee63
6dcf9601-ca7d8d80
a38f69b3-b59f7663
e40b2032-d1d3d50
"
chrome://version/#:~:text=Google%20LLC,b59f7663%0Ae40b2032%2Dd1d3d50

Use "Zero results found" rather than "No data available in table"

If a bug query returns zero bugs, mediawiki-bugzilla currently displays a single row in the table with text:
"No data available in table"

One of the following would be more helpful (and satisfying to see, when the table is a list of blocker bugs that you've just burnt down!):
"No bugs found"
"Zero results found"
"Zarro results found"

Now I know the term "bug" can be renamed, so we might want to avoid using "bug" if we want to maintain compatibility with non-Mozilla Bugzilla instances.

The string comes from:

"sEmptyTable": "No data available in table",

http://datatables.net/reference/option/language

Cannot specify multiple values for a single column

Take Bugzilla REST example, if we want to search bugs that are critical or blocker,
E.g. component=XML&severity=critical&severity=blocker
https://wiki.mozilla.org/Bugzilla:REST_API:Search#Single_Value.2C_Multiplicable

With the following syntax, it would not work

<bugzilla>
    {
        "component":"XML",
        "component_type": "contains",
        "severity":"critical",
        "severity":"blocker"
    }
</bugzilla>

It seems that only the last option, "severity":"blocker", will be taken into account for the query.

Thanks.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.