This site has been archived and you can no longer log in or post new messages. For up-to-date community resources please visit

eZ Community » Forums » Extensions » Helpdesk extension tutorial

Helpdesk extension tutorial

Helpdesk extension tutorial

Thursday 21 July 2011 2:25:05 pm - 10 replies

Hi all,

I am volunteering for a mid-sized NGO called Engineers Without Borders Germany. We are looking to organize our volunteer IT support. In order to do so we would like to install a helpdesk system, whereby somebody can post a ticket, that is assigned to an existing or external user. After having resolved the problem the ticket may be closed. Notification should be done via Email.

We are using eZPublish as our CMS for some time based on ezwebin standard. We do not dispose over much expertise on customizing extensions and so forth and we do not have a budget to pay for that. In order to avoid installing other open-source tools to do this job, I ask you as the community whether somebody has done this based on eZPublish already and whether this somebody is willing to share/generated a step-by-step tutorial on how to realize that.

Thanks for the attention and best wishes


Thursday 21 July 2011 5:38:33 pm

I think this could be a good start:

I've never tested it, so I don't know if it could be successfully modified for the 4.x series...

Friday 22 July 2011 12:04:38 pm

I was planning on building a customer portal/ticket system for my own business.  If there were a financial incentive I'd make it a priority...

Friday 22 July 2011 9:09:10 pm

@Steven: unfortunately we do not have funds for software development. Thanks for the offer

@Sandra: thanks for the hint. I checked out the trunk and started fumbling around with it

  1. adapted some overwrite template settings
  2. changed $ to is_set($
  3. assembled the class definitions since the class definition package would not install

I can now generate a ticketsystem object and view that within the admin view. I thus though receive the following error:

Unknown template variable 'ui_context' in namespace ''

I cannot find any solution for this one. Does anyone know whether some environment variable needs to be passed within the template structure?

Any hints are very welcome.

Best wishes


Saturday 23 July 2011 1:48:01 pm

Understandable, if and when I ever get around to doing it I'll probably put it up on projects.

Is the ui_context error actually causing problems?

Saturday 23 July 2011 2:33:48 pm

I also have had the idea of such a project in the backburner for a long time, my goal being to create a drop-in replacement for Sadly I think I will never have enough time to implement it.

Here are my development notes (brain dump):

Content classes:
. issue
- id (int, autogenerated)
- name
- type (bug, fr, security bug, taks) Note: sec. issue have different perms!
- severity
- status (obj state?)
- relations (different obj relations attributes ?)
- affects ( obj relation / eztags / multiselect ?)
- fixed in ( obj relation / eztags / multiselect ?)
- description: rich text
- attachment (needs one or more => use children objs?)
- component(s) (eztags ?)
. issue_comment
- rich text
- attachment
Workflow events:
. change state to sec. issues upon creation to make them invisible ?
. update issue last modif. date upon adding a comment (for proper sorting)
Misc issues:
. shall we keep whole history of issues, as we do now?
. relation between issues: make sure it can be easily traversed both ways

Saturday 23 July 2011 5:34:54 pm

I don't want to hijack Sebastian's thread here... but I was thinking more along the lines for business purposes, which is why I don't see anything out there that is good enough.

So start with an issue object - each issue is related to a customer group that can have multiple users, each customer group is related to a contract object they are under at the time.  All the fields of the issue that can be are related objects (severity, status, request type, affects) etc.  That way they can be easily added to.  Related objects for related issues.  Then of course the xml block for the description and the date fields opened, closed.  All other interaction can be a sort of comment class which would be a child of the issue but with the abilty to upload files too... a couple of extras could be sms notification on the highest priority issues and wrap everything up with

Now if anyone has this or wants this... let me know.

Saturday 23 July 2011 6:46:35 pm

@Sebastian: I don't know if this may help you, but in this article

David Linnard explains very well the basic differences in templating between versions <= 4.2 and versions  4.3 and onward.

Saturday 23 July 2011 10:42:47 pm

@Sandra: thanks for the hint. I started reassembling the extension according to the tutorial. Unfortunately just changing for

 $tpl = eZTemplate::factory();

Does not work. I'll keep on trying.

Modified on Saturday 23 July 2011 10:47:08 pm by Sebastian Schoeller

Monday 25 July 2011 7:05:47 pm


a couple of small hints:

Friday 16 December 2011 8:04:44 am



Apologies for my late reply but I was inspired tonight by reading your comments here in this forum thread.

I thought I might try to make a suggestion. I realize I may be too late to be helpful but I thought I might at least try, another user might be helped by my suggestion.


I've actually been at a company christmas party all night and i'm not quite 'right'.

Also I've not been in front of an eZ Publish installation in two days or so ... I don't really have any recent experiance or background to support what I am about to say at all, sorry, I want to help but I really only have time tonight to make a suggestion.

If you are still in need of support, say so here in the thread tomorrow afternoon and tomorrow night I can really turn up a copy of eZ Publish and I'm fairly certain I can help you solve this problem (and more importantly test my suggestion).

Ok ... here we go ...


First, I don't use the template variable 'ui_context' very much I think, another reason I'm just not familiar with how it is set (in a template; to be available (for use within said template) to the template which is trying to use it; oh yeah! fyi that is your error message meaning by the way, the error tells me as a developer that the error is specifically an error related to a template, trying to use a variable which is not available, that error specifically says that the variable name 'ui_ocntext' is not available or set by the module view (which sets template variables and loads the template itself) BUT the template is trying to use it regardless (which is bad, and can screw up the page display / functionality of the page greatly)


So not knowing where or how it's used and too tierd to do the work tonight, I turned to my friend Google.


I can find almost anything with a little practice building up search queries! First I look for how ui_context string is used in ezpublish code online,,or.r_gc.r_pw.,cf.osb&fp=23bc058ba87a7947&biw=1014&bih=633


This gives me some good hints and ideas of where to go next with this ...


So not knowing what's really going on (I searched all this out before I really started thinking)

I look at some default module view definition code,

Content module is a good module to review because it may very well be the most used (but not realized) module in eZ Publish! It's quite a module I must say, ok enough day dreaming about my secret love for the content module sigh .... I guess not so secret anymore.


Then I back track a minute to show you the error as I found it in the ticketsystem extension templates,


Notice the usage of 'ui_context' in the template,

{if eq( $ui_context, 'edit' )}

That's what will trigger the template error you described :\


Ok that's the usage, we don't really need to know that to solve this so we move on ...


Take a moment to notice one detail which -may- not be important, need more sleep and eZp testing to remember one way or the other ... :\

See how this module definition for the ticketsystem module view definition code, does not include code to define any values using string, 'ui_context' here,


But if you notice in the content module view definition code there was a 'ui_context' defined, here is a snippet so you can search for this and read the related code, 'ui_context' => 'edit', notice that most module views in the content module view definition code also define this variable. Worth noting I think it might not hurt to define this in a similar way in the above ticketsystem module view definition code. This would be a code change you would need to make yourself and test the results to see if it helps solve the problem.



Save yourself some time stop reading the rest of this thread (for a moment at least).

The above is the right answer (which we prove at the end of the post)Make the above change and the bug is correctly solved once and for all. 

Sorry folks, I go on and on with small answers for two hours, before I find out I was right and knew it in the first 15 min of writing this post!

But I was week in the subject of math in high school so I always feel I must 'prove it' or it is not real or accurate. Scientific method and all you know ...


But ... we are not done yet cause even if the above module view definition addition of 'ui_context' is helpful, this alone (to my knowledge) will still -not- set the variable within a template on your behalf.

I checked the default content module views and could find non which set a template variable 'ui_context' directly. So I was uncertain what to look at next and so I got lost for a few minutes ...


Looked for more info from others on how they have used/ran into this or similar issues in the past l...

I found a great thread that is very close to being helpful, or almost could be, if it was not so old the documentation that was published is now long since taken off the web,

I know this is offline for a fact but I'm not proud as to how I know this, sorry I can't prove it or care to take the time to explain why it happens and why it crushes my heart into pieces every time they damage the community at large when they do things like this ... because now X years later we need the docs they took offline so I can explain this feature ... grrr ... moving on ...


So I moved from forum threads (no help there, but you prolly knew that already) so i moved on to searches, searches showed too few results to be worth sharing but I did find two pages which may be a little helpful.

First there is this page which also contains the text 'ui_context' in a module definition example php file code being defined / used. The page also talks abit on how all this module def php code works with eZ publish policy permissions,


Then I found another page which set me back on the right track, if the module does not set the variable then it must be set in a template which this page indicates it's even supposed to be set within the pagelayout.tpl template! (Search this page for string, 'ui_context' and read a bit more about it's use)

"The user interface context in which eZ publish is in while the current page is being shown. This variable is used by the administration interface to distinguish between different modes (for example "navigation", "edit", "browse", etc.)."

The above text also supports my above findings regarding the php code additions you must make to the ticketsystem module view definition file. FYI I would make the module view definition php code changes I described above now if you still have a need to solve this bug. But keep reading just a bit more, I know I try other patience with my verbose messages at times but we are almost done just a few more details to cover then I can go get some much needed sleep ...


Ok the hard part is going to be finding the definition in template of this variable quickly without access to eZ ...

I look in ezwebin templates, no definitions only usage of the variable in question.

Then I get really nervous, that should have worked according to the above page about pagelayout.tpl variables set ... How am I going to finish this thread post if I can't finish it 100% with complete answers ... man, my boss would not want me to post this if it does not solve the issue 100%. The pressure starts to warm the room just a few degrees, and it's winter!

I race to check the default design(s) pagelayouts, no definitions (in any of them!?!)

Panicking I begin to fall back, searching the wayback machine for any chance the above referenced offline documentation page,*/*

But ... it never successfully retained a copy of the one page we need.

I did find the parent release article in the archives,

But as you can tell you can not use the above link to link to the missing documentation (which is not in the archive). Crushed again, I stumble to the side of the road gasping for breath, looking all around in the pitch black darkness that surrounds me on all sides ...


Then it hit me like a passing car. The past, I can time travel my way through the briar's patch!

I'm always hearing kracker brag about how he time travel's his way through even the sickest arrays of dependencies. I think that will work, breath invincible and never stop. Time to out run even the precious 'doctor' aka john smith through out the ends of existence and really see where all this really leads ...


I didn't think I would be this far down the 'rabbit hole' as it were ... an hour ago when I started writing my reply. 


Then I fell asleep for a few minutes while still sitting at my desk, hands on the keyboard, when I jolted up again I had a thought. I'm done playing games here tonight in trying to solve this issue, i'm going to directly connect to a copy of eZp I can grep/search for this usage/definition/etc/anything at this point.

I'm really starting to think that the module view definitions really are where this is set and the system will pass it to the templates for you ...


I'm cutting to the chase at this point, Then I find a line of code which does define a object variable based on the module view definition of 'ui_context',

 But I could find no related traces which used either variations of the string regardless of formatting. The end, or so I thought for about 7 seconds before I launched into action.

If the module definition defines it, and the module class uses it, then module result might have it.

I looked through all lib/ dir and kernel/ dir (and many more) looking for it before i just did a directory listing and stared at the root dir of ezpublish thinking about where I am forgetting to look ... then I saw it. The index(es), specifically index.php file. So I grep and find this,


Exactly where the module view result containing the module result variable for 'ui_context' being defined! I was so relieved and happy to see this one line of code tonight, omg. here is the line, '$moduleResult['ui_context'] = $module->uiContextName();'  That is the first part of what we expect, but ... my grep showed more so I kept reading down the file.

Then I found it, the very line that had kept me up for almost 2 hours. This just goes to show as proof we all spend insane amounts of time working with eZ Publish and we still love it, even when it takes away our time and makes us search endlessly for answers. The exact place the pagelayout template variable 'ui_context' is being set and made available,


Sorry, I like to share the story sometimes with the answers. Turns out I wasted my time. I knew the answer accurately in the first 15 minutes.


Enjoy using ticketsystem extension with one less functionally crippling bugs. FYI, someone should cross post a bug report on the project forums, just create a new thread and spam the forums. Xrow may never fix the bug (sadly they are quite slow in this regard), but it might help others in the future who are searching for this answer specific to the extension.


Take care. I really really really hope this madness helps someone else time traveling in the future or just someone else using eZ Publish with the ticketsystem extension.




Modified on Friday 16 December 2011 8:07:40 am by // Heath


You must be logged in to post messages in this topic!

36 542 Users on board!

Forums menu

Proudly Developed with from