Hide Queues from Customer New Ticket

[netjess]

Hello,

I would like to hide system queues, like Postmaster, from the Customer New Ticket drop down selection.
I have read and tried to implement http://wiki.otterhub.org/index.php?titl ... _Front_End
But maybe I am doing it wrong? I tried to create the ACL in Admin Panel > Ticket Settings > Access Control Lists
See screen shot:
https://drive.google.com/file/d/0Bw6Psj ... sp=sharing

The above did not work.

I have looked at editing SysConfig > Ticket > Frontend::Customer::Ticket::ViewNew > CustomerPanelOwnSelection
This will be cumbersome listing all the queues that I want to list rather than the few that I don't want to list.

Thank you.

[crythias]

viewtopic.php?f=60&t=7138&p=28109#p28109

[netjess]

viewtopic.php?f=60&t=7138&p=28109#p28109

In the above post You mention:
2) Restrict the Queues available globally through Custom Queues in Sysconfig
3) Restrict the Queues available to a customer via Customer Groups

But you don't say how to do those things.
I am using LDAP. I see in the Admin panel "CustomerUser Groups". If I click on it, it reports that the feature is disabled. I do not know the impact of that or if it will work with LDAP.

I found your post viewtopic.php?t=7531 but it does not match v.4. The reference does not exist.
Ticket -> Frontend::Customer::ModuleRegistration
CustomerFrontend::Module###CustomerTicketOverView

Is it moved or should I create it somehow?

Thank you.

[netjess]

viewtopic.php?f=60&t=7138&p=28109#p28109

The reference does not exist.
Ticket -> Frontend::Customer::ModuleRegistration
CustomerFrontend::Module###CustomerTicketOverView

Is it moved or should I create it somehow?

Excuse me. I found it. And I think I crossed threads. Sorry.

[netjess]

I am still not clear on how block regular users from seeing System queues.

2) Restrict the Queues available globally through Custom Queues in Sysconfig
3) Restrict the Queues available to a customer via Customer Groups

If I use option 2, will it prevent email ticket creation that currently go to System::Postmaster?

I am not sure how to leverage option 3 to block view of the queues.

Thank you.

[crythias]

2) Restrict the Queues available globally through Custom Queues in Sysconfig

If I use option 2, will it prevent email ticket creation that currently go to System::Postmaster?

Not unless you change the Sysconfig Postmaster default Queue. That's a separate entry. Note that Postmaster actions/filters are completely unrelated to web frontend ACL.

Edit Config Settings in Ticket -> Frontend::Customer::Ticket::ViewNew
CustomerPanelOwnSelection:
Determines which queues will be valid for ticket's recepients in the customer interface.

3) Restrict the Queues available to a customer via Customer Groups

Note that with CustomerGroupSupport enabled, Customers will only see Queues match group membership of the Customer. By default, that's CustomerGroupsAlwaysGroups (users). Note this also prevents Customers from seeing tickets in queues of groups of which the customer is not a member.

Or ACL.

Code: Select all

$Self->{TicketAcl}->{'198-Filter-Queues'} = {
    # match properties (current values from the form)
    Properties => {

        # the used frontend module
        Frontend => {
            Action => ['CustomerTicketMessage'],
        },
    },
    Possible => {
        # possible ticket options (white list)
        Ticket => {
            Queue => ['QueueA', 'QueueB'],
        }
    }
};

The above was coded by hand. Not responsible for typos.

[netjess]

Edit Config Settings in Ticket -> Frontend::Customer::Ticket::ViewNew
CustomerPanelOwnSelection:
Determines which queues will be valid for ticket's recepients in the customer interface.

crythias,
Looking at this it seems that it becomes very cumbersome to manage.
I have a lot of queues and from what I see it looks like I will have to remember to come back to CustomerPanelOwnSelection and update any time more queues are added.

Do you know of a way to allow all queues except, rather than block all queues except?

Thank you so much for your help.

[crythias]

acl, possiblenot...
or customer group support, nonmembership.

[crythias]

I have a lot of queues

If you do, maybe rethink switching to services instead. Queues should be a very short list and not be customer related. Services should include all trackable things your agents handle.

[netjess]

If you do, maybe rethink switching to services instead. Queues should be a very short list and not be customer related. Services should include all trackable things your agents handle.

crythias,
Maybe I am thinking about it wrong. Every other system I have worked in, a queue was also considered a category. The type of work, ie: Software, Hardware, Permissions, Maintenance, etc. Then there are sub queues, ie: Software::OTRS, Software::ERP. Services were things like HTTP, FTP, VoIP.
I have some services set up (like mentioned above) but those don't show up for selection when managing tickets. So I am not sure where the configuration went wrong.
Is there an outline or examples of how OTRS is meant to be configured?
I read through the documentation but I don't recall seeing these kind of things mentioned.
It seems to be a cross wire of how it was conceived to operate vs how I perceived it to operate.

Thank you.

[crythias]

I have some services set up (like mentioned above) but those don't show up for selection when managing tickets

Note that Services <-> Customers assigns services to customers (or Default Services for all customers).

Is there an outline or examples of how OTRS is meant to be configured?

http://otrs.github.io/doc/manual/admin/ ... queue.html

I suggest queues being [groupings of] agent that can handle a type of ticket. I suggest that queues be rather broad in categorization with services to narrow this down. SubQueues can do this, too, but Queues plus ACL filtering Services to display probably works well for many purposes.

As a suggestion, Queues probably are individual agents, locations, languages, or Large Categories like IT, Maintenance, Plumbing, Software, Hardware. Services would be like printers, power outlets, sinks, Outlook, Monitors. Services have the ability to have assigned SLA which overrides Queue milestones.

I suggest that Queues not be customer related because it's a maintenance nightmare if you start having many customers. Your agents tend to want to know what they need to do, not so much who they need to service.

[netjess]

Note that Services <-> Customers assigns services to customers (or Default Services for all customers).

http://otrs.github.io/doc/manual/admin/ ... queue.html

I suggest queues being [groupings of] agent that can handle a type of ticket. I suggest that queues be rather broad in categorization with services to narrow this down. SubQueues can do this, too, but Queues plus ACL filtering Services to display probably works well for many purposes.

As a suggestion, Queues probably are individual agents, locations, languages, or Large Categories like IT, Maintenance, Plumbing, Software, Hardware. Services would be like printers, power outlets, sinks, Outlook, Monitors. Services have the ability to have assigned SLA which overrides Queue milestones.

I suggest that Queues not be customer related because it's a maintenance nightmare if you start having many customers. Your agents tend to want to know what they need to do, not so much who they need to service.

crythias,
I appreciate your assistance. Although it appears to me, looking at the Services tab in the Agent Portal, that Services are meant to be specific. As in, not just printers but like "HP 4025 in Accounting". Not just HTTP but HTTP on Web Server web01.mydomain.net. That is the only reason I can think of that there would have been added the Status indicator on the Services Pane.
https://drive.google.com/file/d/0B_elOQ ... sp=sharing

I definitely need to reconsider my structure before I get too much farther along.

I appreciate your guidance.
-Jesse.

[EXG133]

All capitalised words are ITIL terminology.

The Service definition of ITIL:

IT Service (ITILv3): A Service provided to one or more Customers, by an IT Service Provider. An IT Service is based on the use of Information Technology and supports the Customer's Business Process. An IT Service is made up from a combination of people, Processes and technology and should be defined in a Service Level Agreement.

So your example ""HP 4025 in Accounting" could be a Technology part of a Service, but not the Service itself. That could be "Printing" or "Large hardware" or ... whatever you agree upon together with your business.

My interpretation is that that status indicator is meant for a Major Incident or a Planned Outage on a Service.

[crythias]

As far as the specificity of services, I'm of a mind to say "as specific as the criticality of it is similar and that the SLA is the same".

The CMDB and Config Items further map this down for uptime/online. Unfortunately, the CIs aren't (haven't previously been) mappable to a customer, as much as the services have been, so there's a level of abstraction at that point. Yes, you can link a CI to a *ticket* but not to a customer, but the CI can hold all those things (location, serial, model, specs, vendor) that would be unnecessary/overkill in a "service".

[netjess]

OK, I get that. I could see a service being at least "accounting printing". Just "printing" would seem to broad.

Thanks.