Using Support module with Organic Groups

Hi,

since I also wanted to integrate the Support Module with OG, I figured I'd post my solution.

Warning: You have to realize that this is hacking the module, which, depending on your skill level and understanding of the module, could turn out to be problematic when trying to upgrade. Having said that, the modifications are manageable.

The only file edited is (usually located at /sites/all/modules/) : support/support.module

The first thing I did was adding a function which allows me to check whether the current user is in at least one of the groups that the current node is in. I added this function right after support_access():

/**
 * Check whether current user has group access to the supplied node
 */
function support_has_group_access($node) {
  // Get the groups for this user split into an array with format accessible and not accessible
  $groupAccess = og_node_groups_distinguish($node->og_groups_both, false);

  return count($groupAccess['accessible']) > 0;
}

Next I modified the support_access function as follows:

/**
 * Implementation of hook_access().
 */
function support_access($op, $node, $account) {
  switch ($op) {
    case 'create':
      return user_access('create tickets', $account);
    case 'update':
      return (support_has_group_access($node) && (user_access('edit any ticket', $account) || (user_access('edit own tickets', $account) && ($node->uid == $account->uid)) || user_access('administer support', $account)));
    case 'delete':
      return (support_has_group_access($node) || user_access('delete any ticket', $account) || (user_access('delete own tickets', $account) && ($node->uid == $account->uid)) || user_access('administer support', $account));
    case 'view':
      if (isset($node->client)) {
        $client = support_client_load($node->client);
        if (!user_access('view other users tickets') && !user_access('administer support') && !user_access('edit any ticket') && !user_access('delete any ticket')) {
          return (support_has_group_access($node) && $node->uid == $account->uid && support_access_clients($client, $account));
        }
        else {
          return (support_has_group_access($node) && support_access_clients($client, $account));
        }
      }
  }
}

You could stop here, and have it working as expected. Meaning that if you are NOT in the group that this ticket is posted in (could be one or more groups), you can not view, update or delete this ticket.

However, in order to prevent this ticket from showing up in searches I also added a little hack (which is probably not the best way to do it):
I modified the function support_seach by wrapping an if statement around the part where it adds each ticket to the $results variable

// Only add results for which this user has access
if (support_has_group_access($node))
{
    $results[] = array(.........
    //rest of code as supplied by module itself
}

I hope this helps someone ;-)

The code in your example would make the support module dependent on the organic groups module. This is not desirable for anyone not using og. I would much prefer a solution which involved enabling another module, ie support_og, which once enable implemented the above type features.

subscribing

I am also using both Support and og and have been wondering how the support module and og might best be integrated. Having Support external to og certainly is best for some use cases and including with og could be useful in other cases.

An addon module would be a great way to select these features.

Izzy

@jeremy #3 - I agree it would be better if there is an enabling module to permit Support to work with og

@datune #1 - Thanks very much. The hack works great with the most recent dev version 2010-Apr-06 and the combination of the Support module with Organic groups is very, very useful.

I realize that a patch is not the desired route but I have created one and will attach it for anyone who wishes to use it and hopefully someone can suggest how to create this into an enabling or bridging module.

Thanks,

Izzy

I have changed the title of this issue for clarity, I hope no-one minds.

Izzy

Sorry but I have again tweaked the title for greater clarity.

Izzy

Sorry, I don't have sufficient knowledge to offer code to do this. But, I was wondering if it is possible to modify the Support module to recognize other module grants.

I was also looking at the View unpublished module and patches in the issue thread http://drupal.org/node/606516

It made me wonder if such a solution is created the Support module might be used in conjunction with other access control modules not just organic groups.

Izzy

Hi, I'm looking to build a 'support_og' module with the functionality suggested above - are there any known issues/upcoming changes I should take into consideration before I start building in earnest?

@ben_m

That would be great. I am using the patch from #5 without any difficulties but need to apply the patch to each update.

Thanks,

Izzy

[edit] My apologies this should be in a separate ticket, now created http://drupal.org/node/1262544 [/edit]

I am also wondering if the support_og module might also include a patch (feature) to rename "client" and "clients" to "desk" and "desks" and allow the configuration of og to determine if the groups are clients or projects or whatever. It is really helpful having different desks for each group even if common names are used for the desks. This is along the lines described in an earlier issue, http://drupal.org/node/472290.

I have such a patch which may be rather simple but I can attach it for consideration although it might be better if it were in a separate issue queue.

Izzy

having a slight problem with the hook_access stuff. looks like the support.module is providing the node types and the access rules with support_access(). My module needs to change the access permissions to include ogs. Anyone know of anyway to override another modules hook_access?

Or another way to think about is if support.module could implement a test to check for the existence of a support_og module, if it exists and is enabled then run the support_og_access function otherwise use support_access()?

That way support.module is not dependent on og and we don't have to patch support.

just a quick update:

support_og module is almost finished with the following work flow and features.. these may not be applicable to everyone but my needs are pretty specific - as we deal with hundreds of clients assigning each one a role and setting the permissions results in a huge and unmanageable permissions matrix - using og's to control the permissions is a neater way to control this.

workflow: - (in no particular order)
create og for particular client/s relating to project (this could be the 'desk'?) - set to private and closed.
create role 'clients'
set permissions as needed in support (we only use create, priority and state for clients) and add access tickets permission in support_og (there are no more access - $client - tickets rules)
create support client
create user for client (must be named the same to automatically assign 'client' when creating ticket to the correct client/user)
add user to relevant group/s.
add support ticket as a type that can be used within organic groups.

now when a client raises a ticket it will be viewable and able to be commented on etc by all members of the group. the ticket is linked to the client who created it.

clients cannot see tickets in other groups.

if this module is disabled then support runs as normal - i think the code from support module is overridden in about 5 cases - but i need to tidy a few things up and fix the integrated email* before this is finished.

*when cron/fetch is run - all tickets in a mailbox are seen as updated whether they have been replied to or not.. should be fixed in the next week or so.

It sounds like you are dealing with much larger numbers than us.

We are using groups for clients and/or projects.

We have changed the support term "clients" to "desks" and defined several generic "desks" that are applicable across all our clients/projects. This allows for a further cross section to the tickets which is useful to address the different functions/levels that individuals participate as clients or in the projects.

Haven't done much else as of yet.

Using other notifications modules simply for generality with rest of site and haven't yet made use of email feeds into tickets.

fixed it - problem was me being dumb. I was using the same test mailbox for the client and the user so the subscription email was causing the client mailbox to keep the messages..

@ben_m, ok so where are you at? Is this ready for testing? Are there any proviso's?

@izmeez - i'll be posting a version in the next week or so, just been assigned a few jobs i need to prioritise before i can finish off the last few housekeeping tasks on the module.

@ben_m, I'm not sure if I should open a separate ticket or just continue this thought here as it is related to using OG and Support ticketing together.

I have noticed that what is also needed is a Views relationship for Support client/desk access.

When using og and support, views of recent posts, such as tracker, og_mytracker, and og_my (with field for new content), respect the og node access but not for support "client/desk" access.

This may be a separate issue and part of the Support views module. I will take guidance from others if I should post this as a separate issue or if the module you have developed takes this into account.

Thanks.

I notice there is a module to integrate Case Tracker with Organic Groups (http://drupal.org/project/ctog). Since I have not yet decided between Case Tracker and Support module, I'm leaning toward Case Tracker since I need Organic Groups and CTOG is already available.

Any reason I'll be sorry to use Case Tracker and CTOG rather than Support module and whatever fixes are available to make Support work with OG?

Is Case Tracker a good enough alternative to Support, since it has Organic Groups integration available?

This may be solved through the code committed in issue:
#768354: access <i>client</i> support ticket should deny instead of grant

The code will be in the latest dev tarball, and in the upcoming 1.5 release. Please re-open this ticket if the linked code still doesn't solve the problem.

I haven't had a chance to test this to any great extent but testing the latest dev version from 2011-08-16 on our test server it does appear to be working with organic groups. So far users within specific groups can see tickets within the group and not tickets from other groups. Also the search only lists tickets in groups the user belongs to and not tickets from other groups.

I see this was already marked as "fixed" even though comment #20 suggests this may be fixed. Anyway whether you are looking for reviews or whatever, my experience supports the view that it may be fixed.

I'll report back any other findings with further testing.

Thanks,

Izzy

[edit] sorry, what I said before was wrong, with the fix in http://drupal.org/node/768354 the problem described in comment #18 with support tickets visible in views of nodes is still an issue. I have posted a comment in that issue queue. [/edit]

Changing status to "closed (duplicate)" because this issue now seems to be superseded by http://drupal.org/node/768354