segragation based on URL on single system

[jscole]

Hi.

We have need to create a support panel that will allow the submission of tickets via email and web interface. The problem is, we use this somewhat unconventionally. We have need to support multiple customers for multiple products across several domain names. Each customer needs to be able to only see their issues and we cannot have queues openly visible to a user that shouldn't see them. Please see below for example.

support.domaina.com - leads to customer.pl where a customer can ONLY register for domaina.com and only see queues available to domaina.com
support.domainb.com - leads to customer.pl where a customer can ONLY register for domainb.com and only see queues available to domainb.com
...
...

Agents will need to be able to access some/all of the queues above to work tickets submitted. I know this is obviously possible if we run separate instances of OTRS. Is this possible to accomplish without having to maintain separate instances?

Thank you all in advance. I have looped my brain back upon itself trying to think about this one and am stuck in a loop. I need some outside intervention

[jscole]

Also of note, users on domaina.com and domainb.com and so on may have varied @domain.com based email address. Therefore, I don't think there is a way to group them as a customer and lock it down that way.

[crythias]

Don't use customer based queues.

Queues are for the agents who can solve tickets. They are not for customers.

If you sell widget a to customer x, that's a service, and customer x will only see service(s) that customer x has purchased and has assigned to him. He'll have only one queue to submit to (likely) - support, no matter what domain he's registering to.

But ok, each domain might use a different theme and therefore a different queue (support-domaina, support-domainb) because the .dtl points to the different (hidden) queue and the url points to a different theme.

This doesn't necessarily preclude a customer from seeing his services purchased at multiple domains, but it can possibly be filtered by queue/acl. Maybe. At the point you're looking at such a major undertaking, though, I'd suggest hiring an expert to design this for you.

[jscole]

I appreciate your reply.

The service/queue option you have mentioned seems intriguing. I also watched the video at https://www.otrs.com/feature-add-on/ser ... e-routing/. This could be something we could implement. This seems like only part of the answer though. I would still like to segregate on tld so that customers logging in/registering for support.domaina.com only see services related to support.domaina.com. Does this require running separate instances for each domain? I don't see a way to control user registration to the level I have described.

[jscole]

I have also found this...

http://otrs.github.io/doc/manual/admin/ ... gistration

Is it possible that some combination of the two could be the answer? Even with this, I'm not sure how to make sure that each user that registers enters the correct (matching) data to match to a customer.

[crythias]

given that you're on a page that has a value for the queue already assigned (it's theoretically possible), then you can create an ACL that shows only certain services.

In general, the only problem you will have is the theoretical possibility that George has bought widgetA -a product of domainX - and by weird coincidence also widgetB - a product of domainY - and incidentally hits domainX or domainY and could get ticket help for either product(service) at either domain which, coincidentally or otherwise, just happens to be provided by the same group of people.

At which point, yeah, ok, "Weird, eh? Are you two companies affiliated?" "Oh, no, .... see we look completely different!" "But you have the same IP address..." "No, we're different!"

[jscole]

given that you're on a page that has a value for the queue already assigned (it's theoretically possible), then you can create an ACL that shows only certain services.

My apologies. I'm not sure how I would wind up on a page that has a value for a queue already assigned without logging in as a customer user. Also, I'm not certain how that answers the issue of self signup and services available for self registered customer users.

I guess the best question to ask at this point to move forward is:

Am I trying to do something that is far to complex to maintain on a maintenance and upgrade schedule? Is what I'm trying to do even really a supported option of OTRS? If I have to run separate instances for each product we offer, I understand. I'm just trying to keep it all on one for ease of monitoring and maintenance in the future.

[crythias]

I'm not sure how I would wind up on a page that has a value for a queue already assigned without logging in as a customer user.

First, you log in, then you're presented with the page when you create a ticket. This page is part of the theme that's attached to the domain. The dtl holds the queue (or you can create a module to set the queue ... not a big deal, but in any case, it's the domain/theme combo that determines the queue, not the user, because we know who the user is ... because she's logged in.

Also, self-register? That's a horse of a different color. I don't even know how you want to establish the services (products) that the customer (random customer that you have no idea who she is because your company didn't sell her anything directly and apparently can't verify that she's a customer, but ok...)

See where this leads? (Yes, I don't know what you want to accomplish. I am only interpreting what you've said, and trying to provide what I feel are general best practices on this.) On another side, I think you're trying too hard to do one thing and not another and looking for free validation that your way of accomplishing the task at hand is doable within OTRS. I can't begin to understand the machinations of providing customer based queues *in general*, let alone somehow making that work with customers that self-register. The overhead ... the overhead....

I keep thinking that something like getsatisfaction.com might be of use or maybe hosted OTRS but I'm not sure if the runtime maintenance of the system is less of an issue than the infrequent server maintenance downtime(s) might be. However, with proper staging, both as an on-demand disaster recovery standpoint as well as a test-for-upgrade, you should be able to apply appropriate deltas across all deployed sites with minimal downtime.