[SOLVED] Company Tickets

[mdcockfi]

Forgive me for being dense: I have been researching this for two days now and am still mystified. We simply need to have everybody see everything on the customer.pl Company Ticket tab. It seems to me this should be fairly basic functionality as part of the value of OTRS is to build an organic knowledge base and the lack of ability to search all tickets rather defeats the purpose.

I suspect I am missing something obvious and am in need of some guidance.

[crythias]

We simply need to have everybody see everything on the customer.pl Company Ticket tab

Really? Then everyone should have the same CustomerID, and all tickets should have the same CustomerID.

[mdcockfi]

Absolutely. As I stated: we view as OTRS as an organically growing knowledge base and that can't happen unless all customers (internal employees) have the ability to search on all tickets to see if a similar problem has occurred and what the resolution was; I believe some of the OTRS training material even states one of the main benifits is increased customer "self-service".

That being said; yes, I have spent two days combing over statements such as:

Then everyone should have the same CustomerID, and all tickets should have the same CustomerID.

What I do not find is any clear explanation of how to make this happen. The documentation is somewhat straight forward on how to add the customer_id column to the database and set up the mapping, but I do not see how that is implemented: how is a customer assigned the customer_id when they register? We still want the customer_user_id to be their email address (My Tickets). Then does this customer_id automatically flow to the ticket when the customer creates a new one?

[TechnologyK12]

This surprises me. In our organization of over 10,000 customers, this would be unfeasible. There is the potential that sensitive information would be shared with others who shouldn't see it. Also, the average user is no sophisticated enough to read and interpret each ticket's history that perhaps would lack the context.

We make FAQs of the frequently handled problems that are a bit more user-friendly than ticket histories. The FAQ is a great way via customer.pl or public.pl for users to search for and resolve their own problems.

I'm not sure how many customers you are dealing with here, but perhaps they all need to be read-only agents? The idea of our customers seeing everyone else's tickets scares me a bit, frankly.

[crythias]

I'm with TechnologyK12.

The documentation is somewhat straight forward on how to add the customer_id column to the database and set up the mapping

This is already set up. Everyone gets their own customer_id (not the same as the customer_user_id, which is essentially their login). Tickets store both the customer_id and the customer_user_id.

how is a customer assigned the customer_id when they register?

Why would they register themselves? If this is internal employees, you should be using a standardized source, such as LDAP, for "customers".

We still want the customer_user_id to be their email address (My Tickets)

Random person off the internet gets to see all of the tickets of everyone? You might as well just create a wiki/forum/bulletin board.

Then does this customer_id automatically flow to the ticket when the customer creates a new one

Whatever customer_id is assigned to the customer will be attached to the ticket upon new ticket creation, or changed via Generic Agent (for mass/retro updates) or individually by agents that have ability to change customer on tickets.

In addition, *customers* will not be able to see note-internal that may actually hold the solution to the issue. FAQ is the better option.

[mdcockfi]

This is great; I really appreciate the feedback!

We are a volunteer run non-profit and OTRS is only visible to our internal network so security is not a concern. Also, our volunteers typically serve a 6 month tour of duty so having them register themselves eases the administration effort to my mind. We are also looking at deploying LDAP; maybe this elevates the priority on that initiative...? Regarding the FAQ: yes, that would be ideal; however, right now there are two of us primarily responsible for all IT support and we just don't have the bandwidth to maintain a FAQ to that level. Therefore we are hoping the ability to search, especially with the advanced search capability, will allow "customers" to determine if their issue is documented...we have just recently implemented OTRS and may be completely naive on this...?

So assuming we want to forge ahead and give this a whirl:

This is already set up. Everyone gets their own customer_id (not the same as the customer_user_id, which is essentially their login). Tickets store both the customer_id and the customer_user_id.

Is it possible to assign everyone the same customer_id during self-registration until we get LDAP rolled out?

In addition, *customers* will not be able to see note-internal that may actually hold the solution to the issue.

Ah, now that's a show stopper. So I guess I have to ask: is it possible to have the closed entry, that seems to default to an internal note, visible on the customer interface; or possibly assign the closing entry a different type?

Thanks again for the feedback.

[crythias]

Is it possible to assign everyone the same customer_id during self-registration until we get LDAP rolled out?

I .. guess it might be, but you may have to either hard code it or use a script to adjust it retroactively...

is it possible to have the closed entry, that seems to default to an internal note, visible on the customer interface; or possibly assign the closing entry a different type?

Ticket::Frontend::AgentTicketClose###ArticleTypeDefault
Default value: note-internal
Defines the default type of the note in the close ticket screen of the agent interface.
Ticket::Frontend::AgentTicketClose###ArticleTypes
KeyContent
Specifies the different note types that will be used in the system.

LIkewise in "View Note"
Ticket::Frontend::AgentTicketNote###ArticleTypeDefault
Default value: note-internal
Defines the default type of the note in the ticket note screen of the agent interface. Ticket::Frontend::AgentTicketNote###ArticleTypes
KeyContent
Specifies the different note types that will be used in the system.

-=-=-=-
So, if you set defaults to note-external and don't allow note-internal (search SysConfig and change 1s and 0s) that should help your cause.

[crythias]

Once again, though, If you want that level of openness, maybe you're looking at the wrong tool. A wiki/forum/bulletin board may be more appropriate.

[crythias]

"but how can I assign a CustomerID on account creation?"

For *you* because you want everyone to have the same CustomerID, put an input type=hidden in Kernel/Output/HTML/Standard(better: your own theme. That will survive updates)/CustomerLogin.dtl

"Where?"

Code: Select all

                    <input type="hidden" name="CustomerID" value="MyCompany">
                    #### put the line above this div ####
                    <div class="NewLine">
                        <button id="CreateAccount" type="submit" value="$Text{"Create"}">$Text{"Create"}</button>
                    </div>

Of course, MyCompany should be relevantly chosen. For your case, you will want to also select all tickets in the past and update CustomerID to whatever you choose for "MyCompany".

[leeb]

Hi, I'm the other support guy and had some thoughts here

In addition, *customers* will not be able to see note-internal that may actually hold the solution to the issue.

Ah, now that's a show stopper. So I guess I have to ask: is it possible to have the closed entry, that seems to default to an internal note, visible on the customer interface; or possibly assign the closing entry a different type?

Could we not simply add an external-note on resolution and always make the closing internal-note "Problem Resolved" or somesuch. A little more work, but not killer and it keeps the separation as intended.

Once again, though, If you want that level of openness, maybe you're looking at the wrong tool. A wiki/forum/bulletin board may be more appropriate.

I don't understand how a wiki/forum/bulletin board would help us keep track of tickets. I find the daily reminders especially helpful and the dashboard feature invaluable. For that to work in a wiki, etc. would be a lot of work, don't you think? Sorry, I'm not trying to be difficult I just don't see the relevancy in the greater picture (yes I realize this discussion is only about searching tickets). The ability to link tickets to assets should provide insight to weak equipment in the future. OTRS is much more than just managing a list of problem/solutions.

Thanks for you insights.

[crythias]

external-note on resolution and always make the closing internal-note "Problem Resolved" or somesuch. A little more work, but not killer and it keeps the separation as intended.

Easier still, change the defaults in sysconfig to note-external and don't allow changes to internal. See above post.

I don't understand how a wiki/forum/bulletin board would help us keep track of tickets.

I'm looking at it how I approach this BB. I assume the title is going to include [solved] when it is, otherwise, it isn't. I see new responses to my posts via email notifications (and to forums to which I subscribe for notifications) and I see "unread". I can search/filter on them, etc.

Now, admittedly, there are more functions in OTRS than all this, but if you are looking for a collaborative "how do I solve x problem? let's see what the rest of the infosphere says." ... well, you're soaking in it, basically. Otherwise, see above posts and make everything open by about 4 changes to sysconfig and a slight addition to a .dtl file.

[mdcockfi]

Crythias, thanks for all of the feedback/direction. We are now stepping back and re-evaluating this entire matter as a result. I guess it's good to step out of the trees once in a while....

We envision OTRS eventually being used very broadly across our entire organization and everybody seeing everything...well, nuff said.