Anonymous Login
2020-02-29 05:02 PST

View Issue Details Jump to Notes ]
IDProjectCategoryView StatusLast Update
0000346Third-party ModulesHelpdeskpublic2014-04-05 17:57
Assigned Tocaseydk 
Product Version 
Target VersionFixed in Version 
Summary0000346: Helpdesk search needs to be updated for new search compatibility
DescriptionSince smartsearch have been reworked, helpdesk search no longer works. It can't find the CHelpDeskItem as configured in the modules table. I might have solved part of the issue by replicating the search_hook function found in core modules. It seems this helped a bit, but not enough apparently. Need a little how-to of how this now works as it seems much better distributed in the modules. Feel free to email if this discussion goes beyond the scope of the bug tracker. I use it because you once said this was the best way to get your attention ;) TIA. Eric
TagsNo tags attached.
Attached Files




caseydk (administrator)

There are some docs on this one:

I'm also working to write a general Module Building Guide - - that should identify some of these best practices and what usage should look like.


egemme (reporter)

Ok, that's a beginning, I should have thought about the wiki (I have the same problem up here. I write a wiki for my dev teamates and half of them ignore it).

It is primarily what I understood from what I've seen from other modules implenting hook_search method. However, this still leaves me with plenty of questions since I'm learning php on the go.

First, does this mean the search object for a given module is not needed anymore in .../smartsearch/searchobjects?

And I should miss something because of my poor w2p framework understanding. What makes a class (e.g. CHelpDeskItem) visible to the smartsearch module? hook_search method only, or anything else should be configured?

Thanks again


caseydk (administrator)

As long as the class - in this case CHelpDeskItem - is identified as the primary class of the module, the SmartSearch module should be able to call it directly without any further modification. The module is "registered" by being in the module table.

And that's correct, everything in the smartsearch/searchobjects folder will disappear as we convert modules to use the new search interface. While this just seems like moving around code - and it is - the primary benefit is that each module contains its own search information. You don't have to modify another module to make yours searchable.

And yes, there needs to be more documentation on this. All feedback and suggestions are appreciated. :)


egemme (reporter)

Ok its getting clearer (at least a bit). I have the modules table correctly set for helpdesk module in regards of the mod_main_class, otherwise I think it won't work at all. It works fine. I recently restructured the helpdesk.class.php in order to use php5 constructor style, made what is required to be public (vars and methods), and so on. Helpdesk never worked that good for a couple of months. But why I get this message when searching: Class 'CHelpDeskItem' not found in C:\www\htdocs\web2Project\modules\smartsearch\index.php on line 243? At least, this tells me that smartsearch knows the module's class, but why it can't find it while the w2p core can when comes time to use it?


egemme (reporter)

Does index.php of smartsearch is lacking

include_once ($AppUI->getModuleClass($module['mod_directory']));

just prior the $object = new $module... at line 243? I've seen this pattern in the wiki, at I took the lead at adding this line, and goes further. I still have a bug, but within the helpdesk search config itself.


egemme (reporter)

Beside the little temporary tweak I made to smartsearch/index.php to get thru, I mentioned I still can't see any results from the helpdesk module although I now have no crash (it's a beginning :)).

The reason why I can't see any result is a permission problem. My user group profile has all privileges to the helpdesk module, but nothing particular at any items (i.e. open for all items). This means to me that the checkModuleItem should fall back to checkModule. However, in permission.class.php, there is a comment that says that at line 96, but simply dprint the function call listing, then return $false. Should we rather see checkModule($module, $op, $userid) method instead?


caseydk (administrator)

I'm going to try to duplicate this on my end.

What revision of the HelpDesk and w2p are you running?


egemme (reporter)

Both come from their respective lastest from trunk. Although I tweaked hd a bit for our own use, it is quite in sync with the trunk. hd trunk hasn't move for a long time anyway.


caseydk (administrator)

One quick note...

If you follow the naming conventions for your class and module - where the classname is CMyFile and the folder is modules/myfiles/myfiles.class.php - the autoloader will handle finding and loading the class for you. If you choose not to use this class, you'll have to manually load the class yourself via an include or something similar.

More examples:

Projects module - CProjects - modules/projects/projects.class.php
Todo module - CTodos - modules/todos/todos.class.php

Yes... there are all kinds of exceptions and a simpler naming convention would make more sense. We'll likely have one for v2.0 but we'll still have to support this one.


egemme (reporter)

I think I understand why its all broken. The Helpdesk main class is called CHelpDeskItem while its class file is helpdesk.class.php which doesn't follow the convention you mentioned. I may fix this but won't be able to commit my changes since I slightly customized Helpdesk so it will be hard to retrofit it... Well I'll see.


egemme (reporter)

What do you recommend then?


caseydk (administrator)

Help Desk has been updated to support search but there's something screwy with permissions, so the results don't actually display.

This is in r114 in web2project-mods


egemme (reporter)

I have noticed this for a while now because I had tweaked smartsearch to force loading of CHelpDeskItem class. There is some funny code somewhere in the core code that causes the data not to display. Tweaked it but recently lost it while resyncing with the head revision. Will search what I did in my production version and this may give you a clue.


egemme (reporter)

... and by the way, what you did in Helpdesk is not cleanup... it's a total cure. I wished to do that for a long time. I appreciate. Unfortunately, you'r clean-up brought me some annoyance because I tweaked HD in some places to our own taste. Need to retrofit now.


caseydk (administrator)

egemme, as long as I breathe, I'll annoy people. I'm glad I was able to do something useful this time around. ;) If I had some more time, there are some other things I'd clean up - like moving all the queries to the class to reduce duplication - but my priority is core. I only ventured into this module to track down the search oddities and make it v2.0 compatible.

And on the permissions point, any insight would be appreciated. I'm stumped.


egemme (reporter)

Okay then, I remember what I had to face with. But I don't think it will be of any help though. Prior you reworked the permissions class, I tweaked the checkModuleItem to fall back to a simple checkModule when the $result was null (i.e. were it 'dprints'). It seemed at that time that the !$item condition was not appropriate for HelpDesk which has been poorly designed doubled with a poor naming convention. I attempted to reproduce this tweak with the new permission approach, but this didn't do anything good. I also renamed the helpdesk_items table to simply 'helpdesk' to see clearer. And this didn't do anything neither. I will revert this change anyway since the main thing to do was to rename the CHelpDesk class which you already did.


egemme (reporter)

BTW, where dprint's go? Would be glad to use it as a debug tool


caseydk (administrator)

dprint is still in main_functions.php

It's not longer recursive as it was displaying everything down to the database credentials.


egemme (reporter)

I meant, how can we make it appear? Should I turn on some debug feature of w2p? Which one?


caseydk (administrator)

Not a clue. You'll probably just have to insert dprint() or print_r() where you want them. That's what I do anywhere we don't have Unit Tests.


egemme (reporter)

Ok I got dprint working. By scouting the dprint function, I understood that I had to turn on the debug mode and set a level value corresponding to the value I use in the dprint. This primarily what I asked for.

There's another thing that would greatly help my research. How could I see the actual query string from $q? I thought that $query was a public property, but issuing dprint of $q->$query tells me that I can't access an empty property. Please assist me a bit since I struggle a bit with the oo aspect of PHP.

In fact, the real problem with the helpdesk search is that the hook_search for it is not callable. At least on my install. helpdesk is being picked in the moduleList, but rejected by the is_callable condition. Like I already related, I'm affraid w2p doesn't see the CHelpDesk class correctly in its path.

Though getting the query string out of $q looks trivial in this case now, being able to show public property from any class would be greatly beneficial for me.


egemme (reporter)

I finally understood that I should use $q->query instead of $q->$query to get the property. This $ really annoys me. It reminds me 80's Basic !!

So I made a great advance, but still need some help. I know now that hook_search is callable for helpdesk despite my thoughts. Now, I do need to see the exact query that is being sent the do DB. Actually, the $query property only shows the columns. I wished to see the whole thing from the select to the order by as it is submitted, not broken in parts. Is it possible?


caseydk (administrator)

echo $q->prepare()

will show you the contents of the query in full sql. You can copy and paste that directly into phpmyadmin or whatever.

After I wrap a couple issues with Core, I'll check into it again.


caseydk (administrator)

By the way, I appreciate the attention and thought you have and regularly put into web2project. You're one of the people that makes this fun and keep me motivated.


egemme (reporter)

Yeah, I like to annoy people too ;)

I appreciate you come in helpdesk soon because I'm overwhelmed now. I was on a good clue, but things went crazy.

I've been able with prepare to output the full sql and ran it. It does return rows, however I noticed it is very slow because of the join to task_log table. So, I simplified the query by dropping search and display fields and the table join as well.

From this point, the query class to do things going beyond any logic. Try just keeping item_title and item_summary and you'll see. Query class throws an error where the helpdesk.item_id column doesn't exists. Normal, the table name is helpdesk_items. Furthermore, since there is a table alias defined to 'h', I noticed that the search and display fields you implemeted in the hook_search where not prefixed as opposed to projects for instance. I fixed this without any improvement. For a funky reason, the query class alters the column list on the fly somewhere because as far as I dprint the sql string, it has been built as wished by the smartsearch query builder...

So, I'll wait you finish your stuff come into hd. Just let me know when.


caseydk (administrator)

Resolved in core r1225 but there's an issue with the Helpdesk view itself..

-Issue History
Date Modified Username Field Change
2010-01-02 05:43 egemme New Issue
2010-01-02 21:44 caseydk Project v2.0 Release (Closed) => Third-party Modules
2010-01-02 22:08 caseydk Note Added: 0000705
2010-01-03 05:41 egemme Note Added: 0000706
2010-01-03 09:35 caseydk Note Added: 0000707
2010-01-03 14:00 egemme Note Added: 0000710
2010-01-04 03:25 egemme Note Added: 0000713
2010-01-04 10:01 egemme Note Added: 0000714
2010-01-04 12:17 caseydk Note Added: 0000715
2010-01-04 12:35 egemme Note Added: 0000716
2010-01-31 22:28 caseydk Category => Helpdesk
2010-02-26 22:23 caseydk Note Added: 0000763
2010-03-02 17:28 egemme Note Added: 0000765
2010-03-02 17:35 egemme Note Added: 0000766
2010-06-10 22:57 caseydk Note Added: 0000992
2010-06-11 17:39 egemme Note Added: 0000996
2010-06-11 17:41 egemme Note Added: 0000997
2010-06-12 07:31 caseydk Note Added: 0000999
2010-06-15 16:43 egemme Note Added: 0001046
2010-06-15 16:47 egemme Note Added: 0001047
2010-06-17 13:29 caseydk Note Added: 0001062
2010-06-17 14:01 egemme Note Added: 0001063
2010-06-17 19:37 caseydk Note Added: 0001064
2010-06-19 05:01 egemme Note Added: 0001071
2010-06-19 05:48 egemme Note Added: 0001072
2010-06-19 08:15 caseydk Note Added: 0001073
2010-06-19 08:16 caseydk Note Added: 0001074
2010-06-20 04:56 egemme Note Added: 0001075
2010-07-01 21:46 caseydk Status new => assigned
2010-07-01 21:46 caseydk Assigned To => caseydk
2010-07-03 21:31 caseydk Note Added: 0001109
2010-07-03 21:31 caseydk Status assigned => resolved
2010-07-03 21:31 caseydk Resolution open => fixed
2014-04-03 14:37 caseydk Status resolved => closed
2014-04-05 17:57 caseydk Category General => Helpdesk
+Issue History