OK ...
The problem is indeed because of the join. For the global fulltext searching, we produce a where clause like this:
Code:
WHERE
(
MATCH (
`travaux_taches`.`travaux_taches_nom`,
`nkqs9_users_0`.`name`,
`travaux_taches`.`travaux_taches_commentaire`
) AGAINST ('compo*' IN BOOLEAN MODE)
)
... with all the elements you've included from that list as searchable in one MATCH (...) AGAINST statement. Unfortunately, MySQL doesn't let you include fields from multiple tables in a single MATCH, and the way it needs to be is ...
Code:
WHERE
(
MATCH (
`travaux_taches`.`travaux_taches_nom`,
`travaux_taches`.`travaux_taches_commentaire`
) AGAINST ('compo*' IN BOOLEAN MODE)
OR
MATCH (
`nkqs9_users_0`.`name`
) AGAINST ('compo*' IN BOOLEAN MODE)
)
I think this is fixable. I'm looking at the code now. It's not trivial, but as long as I can get it done in the next 30 minutes or so, I'm happy with including it in the cost you've already paid for the basic evaluation of the problem. If it turns into a more complex task, we may have to bill some more time, or you may need to just turn off searching of the user name.
Note that one other issue I think we will run across is that the #__users.name field won't automatically have a fulltext index built on it. That's another issue entirely. When you specify an element to use in global search, we usually automatically create a fulltext index for it. But for join elements, where the column needing indexing is on a different table, that becomes somewhat problematic. Again, possible to fix, just one of those things we've never got round to, as it's such a corner case issue.
So if I do get the basic WHERE clause structure fixed, you'll still need to create a fulltext index on that #__users.name column by hand, in something like phpMyAdmin.
-- hugh