[patch] Support for query: link syntax in WikiFormatting

[cboos@…]

The proposed addition is quite simple: the query: string should be followed directly by the GET arguments.

As long as the query module uses the GET method, one can compose an arbitrarily complex query, and then copy/paste the link from the Web browser to the wiki page editor.

WikiFormatter.py

@@ -116 +116 @@
               r"""(?P<tickethref>!?#(?P<t_intertrac>[a-zA-z]?)\d+)""",
               r"""(?P<changesethref>!?\[(?P<c_intertrac>[a-zA-z]?)\d+\])""",
               r"""(?P<reporthref>!?\{\d+\})""",
-              r"""(?P<modulehref>!?((?P<modulename>bug|ticket|browser|source|repos|report|changeset|wiki|milestone|search):(?P<moduleargs>("(.*?)"|'(.*?)')|([^ ]*[^\., \)]))))""",
+              r"""(?P<modulehref>!?((?P<modulename>bug|ticket|browser|source|repos|report|query|changeset|wiki|milestone|search):(?P<moduleargs>("(.*?)"|'(.*?)')|([^ ]*[^\., \)]))))""",
               r"""(?P<wikilink>!?(^|(?<=[^A-Za-z]))[A-Z][a-z]+(?:[A-Z][a-z]*[a-z/])+(?=\Z|\s|,|\.|:|\)))""",
               r"""(?P<fancylink>!?\[(?P<fancyurl>([a-z]+:[^ ]+)) (?P<linkname>.*?)\])"""]
 
@@ -258 +258 @@
                 return self._href.wiki(args), '%s:%s' % (module, args), 0, None
         elif module == 'report':
             return self._href.report(args), '%s:%s' % (module, args), 0, None
+        elif module == 'query':
+            if args and args[0] == '?':
+                return self._href.query() + args, '%s:%s' % (module, args), 0, None
+            else:
+                return self._href.query(), '%s:%s' % (module, args), 1, None
         elif module == 'changeset':
            cursor = self.db.cursor ()
            cursor.execute('SELECT message FROM revision WHERE rev=%s', args)

[cmlenz]

Good idea. What I was planning was to use a kind of mini-query-language in the link, in conjunction with the more powerful query capabilities currently being worked on on the query branch.

For example:

    query:milestone=0.9&owner=cmlenz&keywords~=layout&severity!=enhancement

Meaning: all tickets with milestone set to 0.9 and owner set to cmlenz, where the severity field is not set to enhancement.

Operators supported might be:

=	is
!=	is not
~=	contains
!~=	does not contain
=	begins with
$=	ends with
>=	greater than
<=	less than

Note that the range of available operators will be dependent on what can be represented in the new query UI, rather than on whether they're technically implementable.

For fields like status, resolution and custom fields of type "radio", you could OR option values, for example:

    query:status=new|assigned|reopened

[cboos@…]

Yes, I understand that there's the room/need for a custom query mini-language...

Nevertheless, my proposal still stands:

• if the first character after the query: is ?, use what follows directly to form the query (the simple copy/paste way)
• if not, parse the arguments according to the rules presented above (the query mini-language way)

[cboos@…]

Just a reminder for this patch, which I find quite useful as it is now:

Form a custom query using the web interface, then copy everything after the '?', and paste it in your link after the '?':

[query:?<paste the query here> Reopened Bugs for XYZ]

[cmlenz]

Implemented in [1362].