Managing Multiple Companies

[roe1234]

We are trying to use OTRS to manage multiple company's tickets. However, there doesn't seem to be a way to automatically associate 'customers' with queues when they create customer accounts. The ideal case would be to use the domain part of the email address to make a decision for what queue they can see. This feature exists when people submit tickets via email; I am able to route their ticket to their company's queue. The best I can figure out is to not allow newly registered users to submit tickets at all through the web interface until an admin assigns them a group. This would work fine except I can't alert the admin that a new customer has been registered.

To recap:
1) Can web-registered users be automatically joined to their company's group based on their registered email address?

2)Can admin/agents be alerted when a user registers via customers.pl?

Does anyone else do something similar? If so, how do you handle this problem?

[crythias]

However, there doesn't seem to be a way to automatically associate 'customers' with queues when they create customer accounts

You wouldn't. Queues are assigned to groups. Customers are assigned to groups ('users' by default on creation).

No provision in Kernel/System/Web/InterfaceCustomer.pm provides notification. Check around line 627.
Line 648 sends the customer confirmation.

Kernel/System/CustomerUser/DB.pm contains the database CustomerUserAdd which logs the addition, but this isn't a ticket Event, so, in my opinion, updating InterfaceCustomer.pm around line 648 to include the notification would be a preferred way to handle it in your case.

[vinnie2k]

We suck all the people from our AD and have them as customers.

Does that help in the same issue as described above, i.e. determine the queue as a function of the domain name?

I don't want to create customer accounts for 25'000 people.

[vinnie2k]

Posting replay to my own: CustomerGroupSupport?

[crythias]

You wouldn't export/import active directory. You'd use it as a LDAP backend and use the customerAlwaysGroups entry for the connection for the group membership. Queues would belong to group. If you want to segregate available queues for your grouping, I'd suggest using multiple backends and CustomerAlwaysGroups for each backend, with filters applied.

If you have more than 10 queue groups that need to apply, then that may require a bit of adjustment in Customer Auth and Customer User to increase the number of backends available.

[vinnie2k]

Yes we do use AD as an LDAP backend

So we'd setup one LDAP backend per company, and then attach one backend to one group, and one queue to one group.

(business case is: multiple companies each having their own first level support, plus IT community across multiple companies having a single global support).

Thanks for the idea!

[crythias]

Well, alternative to that might be a CustomerID that is used in an ACL.

[vinnie2k]

Which ACL might that be?

[crythias]

Create one in Config.pm http://forums.otrs.org/viewtopic.php?f=60&t=11235

It doesn't explicitly mention what you can use but

Code: Select all

                for my $Item ( @{ $Step{Properties}->{$Key}->{$Data} } ) {
                    if ( ref $Checks{$Key}->{$Data} eq 'ARRAY' ) {
                        my $Match4 = 0;
                        for my $Array ( @{ $Checks{$Key}->{$Data} } ) {

(System/Ticket.pm)
Seems to indicate that anything that can be used from CustomerUserDataGet (for example, UserCustomerId) can be used as an Entry in Properties=>

I haven't fully tried it out, but that's what appears to be the case.

[vinnie2k]

Thanks