Page MenuHomePhabricator

Paraminfo for parameter "generator" of the query module shows too many types
Closed, ResolvedPublic

Description

Author: a.d.bergi

Description:
Currently opened the url above, and wondered why there are so many possible values for the "generator" parameter. More exactly: all names from "prop" and "list" are listed there!
Thats wrong, a quick filtering against the isGenerator-attribute of each querymodule shows that the following querymodules are listed there in spite of they are not usable as a generator:

  • allusers
  • blocks
  • deletedrevs
  • filearchive
  • logevents
  • tags
  • usercontribs
  • users
  • gadgetcategories
  • gadgets
  • globalblocks
  • abuselog
  • abusefilters
  • info
  • revisions
  • iwlinks
  • langlinks
  • imageinfo
  • stashimageinfo
  • extlinks
  • categoryinfo
  • pageprops
  • flagged
  • globalusage

Version: 1.18.x
Severity: minor
URL: http://de.wikipedia.org/w/api.php?action=paraminfo&mainmodule&pagesetmodule&modules=query

Details

Reference
bz32688

Event Timeline

bzimport raised the priority of this task from to Low.Nov 22 2014, 12:03 AM
bzimport set Reference to bz32688.
bzimport added a subscriber: Unknown Object (MLST).
		// Allow the entire list of modules at first,
		// but during module instantiation check if it can be used as a generator.
		$this->mAllowedGenerators = array_merge( $this->mListModuleNames, $this->mPropModuleNames );

It's prevented from being used in code

		$generator = new $className ( $this, $generatorName );
		if ( !$generator instanceof ApiQueryGeneratorBase ) {
			$this->dieUsage( "Module $generatorName cannot be used as a generator", 'badgenerator' );
		}

Looks like it's just an output issue.. Because the filtering (in makeHelpMsgHelper) hasn't taken place

Lowering level

Needs a bit of refactoring to pull that code out, and the setup being done at the top... Or we just poke it and make the filtering before we build the list for paraminfo