Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

In this Discussion

osTicket v1.10 (stable) and Maintenance Release v1.9.15 are now available! Go get it now

Integrate with Drupal 7

Hi everyone,

I have my own software company and I use Drupal 7 for the website because there are modules for everything that I would like to do, apart from the helpdesk. I need a free solution for the helpdesk and osTicket has been the best I've come across so far, however because of the way my licensing system works and because it is likely that sensitive information will be included in the support tickets I need to link osTicket and Drupal in such a way that a user must be logged in to submit or view their tickets.

I have read that some members on here have done this, however I've tried 'including' the drupal bootstrap.inc in the login.php to start with but I just get a blank screen because of conflicts in the database include file for osTicket and Drupal. So I was wondering if anybody would be kind enough to share their solution to this problem, or even offer alternative.

Thanks in advance,
Andy

Comments

  • Preamble
    It just so happens I was doing some off-again on-again work with integrating this into Drupal.

    If you're just interested in ensuring a user is logged you're right, you need bootstrap.inc and you're right you end up with useless blank pages.

    Solution
    I've yet to get to properly documenting, so try this and let me know if I missed something and I'll have another look, however the following should sort the issue:

    Duplicate Function Names
    osTicket uses db_query() and (I think) db_close() rename the functions to something like db_ost_query() and you'll be fine. (Note I put the 'ost' in the middle to help future find/replace) I can't remember whether all occurrences of the function needed renaming for it to work, but its probably a good idea to do it.

    Location of the bootstrap
    The bootstrap has all manner of issues if called from outside the root Drupal directory, I gave up finding an answer to this and just kept an file in the root that osticket would include.

    Headers, Headers everywhere
    Bootstrap seems to like sending additional headers out so you'd want to include your file in an appropriate location (i.e. one of the .inc files). I think this solved everything.

    Disclaimer
    Of course, remember this will break on any updates and any mods you add you'd have to take this into account. If I've remembered rightly this will get bootstrap up and running and you can run is_user_logged_in() and show or redirect the page.

    Further Concerns
    I actually had a greater goal in mind in my meddling and so I don't remember whether everything was perfectly cosy after this addition.

    I do remember having further issues with headers being sent and when fully bootstrapping the system session usage interfering with ostickets sessions - I *think* this occurred later though and shouldn't be an issue for you.

    An Alternative Solution
    When googling, many people suggested simply creating a module and having it iframe the contents inside it, this might be a good enough solution for what you want and would require a whole lot less messing around with ostickets code.

    Let me know how you get on or if my memory is full of holes.
  • Hi foodle,

    Thank you very much for your answer and sorry for my slow reply.

    Strangely, I did think about renaming all instances of db_query() and db_close() in osTicket if nobody replied to this topic. However, I was reluctant to because I thought that there might have been a less 'destructive' work-around, but seeing as though you suggested it and I failed to find a better solution. Fortunately, I was able to do a batch find and replace so it wasn't that hard to do and it did solve the blank screen issue.

    However, now that I've got that problem fixed, the new one is that even though I've put the following code at the top of the client 'header.inc', whenever I try to use a drupal function such as user_load() or user_is_logged_in(), I get told it is undefined. Any ideas why?
    [HTML]
    define("DRUPAL_ROOT", "/var/www/vhosts/mysite.com/httpdocs/");

    chdir(DRUPAL_ROOT);

    require_once '/var/www/vhosts/mysite.com/httpdocs/includes/bootstrap.inc';
    drupal_bootstrap(DRUPAL_BOOTSTRAP_FULL);
    [/HTML]

    It could be to do with the location of osTicket I suppose, but I didn't quite understand what you were saying about the bootstrap. osTicket is in a directory called 'helpdesk', in the root of the drupal directory - is this a problem?

    With regards to the alternative solution, this sounds ok but would I be able to stop people accessing osTicket from outside of the module because if not the support tickets are just as insecure. If so, how would you suggest I did that?

    I just wish there was support for Drupal built in to osTicket because it is one of the best help desk systems I have used, even compared to paid solutions. Perhaps the problems we are experiencing is an indication of why there isn't support though.

    Kind regards
  • I just thought to check this post to see if you replied, so good timing.

    Renaming the functions isn't great, but the bootstrap ends up with a duplicate function, there may be a way to combat this in PHP that I'm not aware of.

    undefined means didn't perform the bootstrap.

    I think mentioned this, but incase I didn't - The code above should be in the root drupal installation directory. I call the file that includes this code from the osticket directory, but that code needs to be executed from the root.

    Try creating a drupal_bridge.inc or some such and require that file in your header.

    For the alternative, I was thinking of checking the url - its horrible, but I figured it would work.

    As far as a built in support, the project was dormant for so long I assume time is short and the undertaking is just a large task that isn't considered a priority. All of ostickets logins use sessions all the checks and calls refer to that session data and to integrate it fully with drupal, there would have to be a whole separate set of code for the drupal login as opposed to the vanilla version.

    This is where I ended up and started spending some time every so often writing alternative calls to the inbuilt session calling, I've pretty much done the client side and just need to copy that over to the staff side (and notice the millions of bugs I introduce) before even considering tidying it up and suggesting you try the same thing.
  • Once again, thank you for your reply. Very sorry for the slow reply! I'm just so busy lately - think I'm trying to do too much at once.

    Anyway, I think you did mention about the code having to be in the root of the drupal installation but I misunderstood. I thought that because osTicket was in a subdirectory in the root of the drupal installation it would act the same, but obviously not because I created a drupal_bridge.inc in the root and included that in the osTicket header and it's behaving a bit better. However, I still can not access the $user global variable or call drupal functions outside the drupal_bridge.inc. I can access drupal functions if I put them within that file though.

    I'll keep trying for a solution but do you have any ideas?

    Update: Just by chance I did a print_r($GLOBALS); to try and see if I could find out what was going on and I came across the following errors, if they help. I'm not quite sure how to rectify them.
    http://pastebin.com/YtHPGD75

    Also, as for the alternative, I really don't fancy doing that on such a site. Maybe if this was just personal, but seeing as though this is for a company website I think there's too much at stake. I'm not really that comfortable doing it this way either, but at the minute it's the best solution I can find! The modules for Drupal 7 aren't terribly good - the closest I've seen to osTicket is 'Project Management', but it seems quite small and restrictive and I fear what will happen in the future. I tried OTRS Help Desk as well but the drupal integration isn't what I had hoped either.

    I know what you are seeing about Drupal 7 integration built in to osTicket, but man - it would be like a dream come true!
  • I think this is the part I vaguely mentioned originally - it all acts very weird and drupals bootstrap brings with it a whole lot of mess.

    Since you originally posted, I've actually got a fair amount of the login process down. People login and it all works fine (client and staff) so its definitely possible. I did this by changing the entire login procedure (client and staff classes) to "if drupal do this instead".

    But as I said its a side project, the code is incredibly messy and I've not tested everything yet. I was also reworking the whole UI to something I'd prefer and adding additional database features osticket is missing - essentially I've gone from "I'd like to login to drupal" to "screw it, may as well rewrite the whole thing". So I guess the answer is it is a mess.

    However, I originally answered because I remember getting to a stage where the system worked like you want it to - it just wasn't what I wanted so I skipped over it.

    I'm going to to have a look through my code and see if I can work it out, but first up, have you considered adding something like the following inside your drupal bridge?

    if(user_is_logged_in(){
    global $yesThisIsALongVariableToStateTheUserIsLoggedInWithoutBootstrap = true;
    }


    Then just have osticket check if its true or not and die() if not.

    As I say I'll take a look and see what on Earth happened all those weeks ago.
  • You’re certainly right about the bootstrap brining a mess, but you forgot to mention it being incredibly picky as well. If you could take a look at what you did before you skipped over it that’d be great, but to be honest I’m starting to think it’s not worth all this effort. I took a closer look at the code last night, and I think that even once I solve this problem there will be a whole lot of problems and hacking to come!

    And mine isn’t just a side project, I planned on using it for my company’s website but now I’m thinking that it is a very bad idea. I’m not too happy with the amount of hacking that will be involved to get this working, and it would be just my luck for a vital update for osTicket to come out, forcing me to start all over again. I’m now looking at using Zendesk as there is a Drupal module that does what I need. Don’t get me wrong I would absolutely love to use osTicket, even if I had a £1 million budget or something, but I simply cannot without Drupal integration built in, as much as I hate to end a topic without a proper solution.

    As for the PHP, I tried that, and thought I’d cracked it. However, I couldn’t seem to access that variable within, for example, login.inc.php no matter what I did! Although, I could access it within the header where I called the drupal bridge.
  • Isn't Zendesk a hosted solution? So you could look into supportsystem.com which is the new hosted osTicket solution. I don't really know a whole lot about it yet, but it might be a viable alternative for you.
  • ntozier;41941 said:
    Isn't Zendesk a hosted solution? So you could look into supportsystem.com which is the new hosted osTicket solution. I don't really know a whole lot about it yet, but it might be a viable alternative for you.
    Unfortunately, yes. Zendesk is hosted.

    The fact that supportsytem.com offers an API looks promising, but do you know where I could see some documentation for it? I might be able to write a module to do what the Zendesk module does, although osTicket doesn't have a username/password login system, so it probably wouldn't be suitable.
  • You may well have decided to go elsewhere for your solution now, but I've gone back over what I had done and the following will take a fresh copy of osticket and provide you access to the $user variable and functions.

    Step 1

    Create a file drupal_bridge.php in your drupal root install directory
    <?php

    define('DRUPAL_ROOT', '/path/to/drupal');

    require_once DRUPAL_ROOT . '/includes/bootstrap.inc';

    $base_root = (isset($_SERVER['HTTPS']) && $_SERVER['HTTPS'] == 'on') ? 'https' : 'http';

    $base_url = $base_root .= '://'. $_SERVER['HTTP_HOST'];

    drupal_bootstrap(DRUPAL_BOOTSTRAP_FULL);

    ?>


    Step 2

    client.inc.php

    line 17:
    require_once('path/to/root/drupal_bridge.php');


    Step 3

    Find & Replace all occurences of db_query with db_ost_query.

    2 of these results are actually mysql_db_query so I do another find & replace:

    Find : mysql_db_ost_query Replace with: mysql_db_query

    Step 4

    include\mysql.php

    Line 42: replace db_close with db_ost_close

    (unused function?)

    Step 5

    index.php

    Line 20: add

    <?php echo $user->name; ?>



    Step 6

    upload and view.
  • I've been following this thread and checking it daily because it interests me. My primary web page is running D7, and while I'm not sure that I would every really need or want to integrate osTicket into that particular site I beleive that other people may find this useful. Thank you for the efforts that you both have put into this.
  • Oh. My. God! It worked! osTicket can now see and access the user that is currently logged into Drupal 7. Thank you so much foodle!

    It seems where I was going wrong was where I was trying to include the drupal bridge. I had put the code in the include/client/header.inc.php file, but for some reason I could only access anything in the file.

    Well, this puts a twist on things because I could probably get osTicket integrated to my requirements now. Ultimately though, I think that compared to the Zendesk solution, it is too risky to put it out on a live company website because it voids updates and I might do something that exposes a vulnerability. However I'm waiting to see if Zendesk will indeed do everything I want, and if it doesn't I will probably end up continuing my hacking of osTicket. Hopefully this topic will still be helpful to others in similar situations though!

    I've been following this thread and checking it daily because it interests me. My primary web page is running D7, and while I'm not sure that I would every really need or want to integrate osTicket into that particular site I beleive that other people may find this useful. Thank you for the efforts that you both have put into this.
    I hope other people will find it useful too. No problem about the effort; I'm just sorry it was a little slow to start with. It's unbelievable how much I've got to do lately! I do owe a massive thank you to foodle though!
  • First off, sorry for not having been clearer from the outset, I hadn't looked at it in a week or so and was going from memory.

    I'm glad you got it working, just pure chance I happened to be looking at this at the time and had the chance to look through my horrible code mess. It definitely breaks updates, but I've learnt not to rely on them here.

    The security issue is something that definitely came to mind when I've been expanding on this to re-write class.client.inc and class.staff.inc. That is where I'd imagine vulnerabilities would appear. As it stands I'm rather trusting drupal's bootstrap to be secure in and of itself. While I've chosen a full bootstrap, you can select certain parts of drupal alone to bootstrap in as needed.

    If you do choose to go down this route and don't mind completely breaking updates the idea in my mind was to suggest you include
    ...|| !is_user_logged_in()...

    at the top of the files (again from memory) that check !$thisclient->isValid() etc and return die() if not to completely block off access to those not logged into drupal.
    ntozier;41968 said:
    I've been following this thread and checking it daily because it interests me. My primary web page is running D7, and while I'm not sure that I would every really need or want to integrate osTicket into that particular site I beleive that other people may find this useful. Thank you for the efforts that you both have put into this.
    I'm sure we've all been through the motions of browsing forums for an answer (actually I went through just this attempting to get bootstrap working at all - hence the bridge file) without any clear outcome, answer or avenue of thought, so hopefully someone in the distant future in which robots rule the world will find this useful.

    I don't want to promise I'll come back with this, but I intend to at least - I have a "working" login for both clients and staff (scp) via drupal login checks, which takes their drupal email and matches it with an existing osticket user's email to display tickets. I'm able to login on both and after a little fiddling it "seems to work"™ so if I'm able to confirm to some extend its safe and get the time to tidy it up for public presentation I will.

    There is a side project among the mess which provides a "ost" or "drupal" login option from ost-config or perhaps system-settings.inc and allows login type to be switched on and off, which would potentially allow the default client and staff classes to run in the standard install. But of course, here is where all those security issues come into play.

    I'll also note a little extra at the bottom here for those people from the future - I had some concerns about the time Drupal bootstrapping actually takes and whether it was noticeable.
  • Hi All,

    Can anyone tell me how to integrate osTicket to drupal?


    Regards,
    Naba



  • Naba read foodle's post(s) in this thread.
  • Can we assign drupal theme to osTicket or how to customize osTicket page design?

    Regards,
    naba
  • Naba, sorry for the slow reply. I have only just looked at this topic again.

    Whilst you cannot directly apply a Drupal theme to osTicket, you can make osTicket look like your Drupal website by editing files such as 'header.inc.php' and 'footer.inc.php' in the 'include/client' directory. You can also play around with the .css files. It does take quite a lot of playing around to get it to look exactly how you want, but I've done it so it's certainly possible.
Sign In or Register to comment.