Ticket Query doesn't return all matching tickets for a query.

[anonymous]

The function array ticket.query(string qstr="status!=closed") does not return all tickets from my server which meet the desired criteria. I have a component with over 30 tickets called D2D. When I run: p.ticket.query("component=D2D") I get the following output:

>>[37, 38, 65, 66, 69, 72, 71]

I also cannot return a query with multiple parameters. For instance p.ticket.query("component=D2D & priority=major") returns:

>>[]

What is the correct syntax?

[Olemis Lang]

Replying to anonymous:

The function array ticket.query(string qstr="status!=closed") does not return all tickets from my server which meet the desired criteria.

I'll take a look at this in a while . Could please mention the versions of Trac and installed plugins ?

[...]

I also cannot return a query with multiple parameters. For instance p.ticket.query("component=D2D & priority=major") returns:

>>[]

What is the correct syntax?

Have you tried p.ticket.query("component=D2D&priority=major") (i.e. no whitespace chars ;) ?

[anonymous]

Trac version: 1.0

tracxmlrpc 1.1.2

No whitespace characters resolved the problem of multiple parameters.

[Olemis Lang]

osimons could you please check ? I do not have Trac 1.0 installed in my dev machine :-/

[osimons]

Replying to anonymous:

No whitespace characters resolved the problem of multiple parameters.

Goodie.

It is very difficult to test your queries for data in you own installation. What RPC does is really execute the query just as if it was called by a user in the Trac query module. Therefore if you went to Custom Query and performed the same query, the results should be identical (like /query?component=D2D in your own Trac instance).

If the lists are not identical, the first place to look is permissions. Perhaps the login from the browser session is different from the RPC request that may use a different user – or even anonymous?

If you turn on Trac debug logging (see TracLogging), the RPC plugin should report a great deal of information about the user making requests, the input received, the permissions checks performed, and the output returned:

[logging]
log_level = DEBUG

... and then have a look at log/trac.log in your project folder.

[anonymous]

Both logins are identical. I gave 'Trac Admin' permissions to all groups to make sure, and nothing changed. The log/trac.log file doesn't give any indication that the user doesn't possess the required permissions, but the dates in the log file only go to 6/9/2015. It seems that only tickets with type='task' are returned by the RPC request. I cannot find anywhere that may restrict the permissions for type. There are 3 additional types (support, defect, enhancement). Any idea where the discrepancy may be occurring?

[anonymous]

Unsure if it is related, but I ran an example from the XmlRpcPlugin site:

The following error occurred at the server.ticket.query method:

[Ryan J Ollos]

Are you using AgiloForTrac?: #11847.

[anonymous]

It is disabled right now, so no.

[anonymous]

Blackmagictickettweaks 0.12.2 is the only plugin that could play a role, but I haven't changed the permissions for any fields and the 'type' field isn't being tweaked.

[osimons]

Replying to anonymous:

It is disabled right now, so no.

I'm not sure disabling will be enough as Agilo code can still load behind the scenes even though visual traces may be gone. The way plugins work is that all code must actually be loaded into Python process in order to discover the possible components, and only then for each interface decide which classes of which plugins should be in the set to be called for the various hooks. Agilo changes Trac at a very deep level, and will likely go well beyond the ordinary plugin mechanisms in order to inject the necessary code behind the scenes.

Could you please try to actually delete the Agilo plugin code (or at least move it out of any path that loads Trac plugins). Then restart your Trac server process.

[anonymous]

It isn't in the plugins folder. It isn't in the configuration file. It only appears on the TracAdmin Plugins list. So I believe it has previously been deleted.

[osimons]

If it is in the Plugins list, it actually loads.

See "About Trac" as TRAC_ADMIN to see where Trac found the plugin.

[anonymous]

It cannot be deleted because it is being used in a different site by another development team within my company.

[osimons]

If so, you need to separate the sites by ensuring that they run in different processes (Python intepreters). Then it is possible to have different set of local plugins (while globally installed plugins will load regardless).

Anyway, this is an installation issue and not an issue with the plugin itself.

[anonymous]

The plugin could be enhanced so that it is compatible with Agilo. Even if I ensured that the sites ran in different processes, we will be using Agilo shortly and the resolution would be invalid. There needs to be XmlRpc compatibility with Agilo.

I'm not convinced that the problem is related to Agilo. All other aspects of the XmlRpcPlugin work as desired. Some most elements of the ticket query work as well. This seems like a plugin issue.

[osimons]

comment:2:ticket:6297 – actually the other way around...

[anonymous]

Why is the on site query unaffected by Agilo if the XmlRpc plugin algorithm works as you say it does? comment:5

[osimons]

That is a question for the Agilo people to answer. If you can close the other site for a couple of minutes and temporarily remove the Agilo plugin (or configure a separate environment for testing), I'm sure you can get some interesting questions to ask when comparing web & rpc queries with & without Agilo installed.