RT and customer relations

RT Users
1

Hello list,

currently our RT is accessible via only from intranet (only special email
addresses routed into it). But now we want that customers can see their
tickets via web, too. So we want to make the server public. But I hesitate
because of some problems.

  1. For convenience we have one queue for each customer. Now if I let
    unpriviledged users see the queues they see all our other customers, too.

  2. Very often we have many different people on the customer side reporting and
    dealing with the tickets. So different users need access to the same tickets.
    Thus a solution like “let unprivileged users only access own tickets” is not
    feasible.

My solution now would be to create one group for each customer, putting all
users working for that customer into that group and letting only this group
access the specific customer queue. Ideally customer users, groups an queues
could be generated/synchronized from an existing CRM database.

Now what I would like to know is, is that a good way to do it? How are other
people dealing with these problems?

Stephan

2

-----Original Message-----
From: rt-users-bounces@lists.bestpractical.com
[mailto:rt-users-bounces@lists.bestpractical.com] On Behalf
Of Stephan Uhlmann
Sent: 22. august 2005 17:26

Now what I would like to know is, is that a good way to do
it? How are other people dealing with these problems?

I’m very interested in hearing a response to this too, since I have the same problem.

Cheers, Bjorn

3

Hi Stephan, I see that you have the same problems that I have had. In this
case there is nothing you can do with unprivileged users.

One of the solutions that we achieved is created generic queues, so instead
of using ‘customer names’, using something like fault type. To avoid
customers searching the queue for all tickets, take away the search
function.

Method 2 is to alter the code so that the customers are created as
‘privileged’ users but only see the ‘unprivileged users’. Because RT is open
source, if you do this, you have to make the source code available to
everyone. If I could program in perl, I would gladly do it.

So far these are the only 2 solutions that I have found.

Best Regards,
Ravin Mathoora-----Original Message-----
From: rt-users-bounces@lists.bestpractical.com
[mailto:rt-users-bounces@lists.bestpractical.com] On Behalf Of Stephan
Uhlmann
Sent: 22 August 2005 16:26
To: rt-users@lists.bestpractical.com
Subject: [rt-users] RT and customer relations

Hello list,

currently our RT is accessible via only from intranet (only special email
addresses routed into it). But now we want that customers can see their
tickets via web, too. So we want to make the server public. But I hesitate
because of some problems.

  1. For convenience we have one queue for each customer. Now if I let
    unpriviledged users see the queues they see all our other customers, too.

  2. Very often we have many different people on the customer side reporting
    and
    dealing with the tickets. So different users need access to the same
    tickets.
    Thus a solution like “let unprivileged users only access own tickets” is not

feasible.

My solution now would be to create one group for each customer, putting all
users working for that customer into that group and letting only this group
access the specific customer queue. Ideally customer users, groups an queues

could be generated/synchronized from an existing CRM database.

Now what I would like to know is, is that a good way to do it? How are other

people dealing with these problems?

Stephan

4

Hi Stephan, I forgot to add that we gave customers a generic login so that
they all use the same username/password so that when they log on, they can
always see the tickets that belong to them.

It is not the best solution, but it is a workaround. If you manage it well,
it works.

Hope this helps.

Best Regards,
Ravin Mathoora-----Original Message-----
From: rt-users-bounces@lists.bestpractical.com
[mailto:rt-users-bounces@lists.bestpractical.com] On Behalf Of Stephan
Uhlmann
Sent: 22 August 2005 16:26
To: rt-users@lists.bestpractical.com
Subject: [rt-users] RT and customer relations

Hello list,

currently our RT is accessible via only from intranet (only special email
addresses routed into it). But now we want that customers can see their
tickets via web, too. So we want to make the server public. But I hesitate
because of some problems.

  1. For convenience we have one queue for each customer. Now if I let
    unpriviledged users see the queues they see all our other customers, too.

  2. Very often we have many different people on the customer side reporting
    and
    dealing with the tickets. So different users need access to the same
    tickets.
    Thus a solution like “let unprivileged users only access own tickets” is not

feasible.

My solution now would be to create one group for each customer, putting all
users working for that customer into that group and letting only this group
access the specific customer queue. Ideally customer users, groups an queues

could be generated/synchronized from an existing CRM database.

Now what I would like to know is, is that a good way to do it? How are other

people dealing with these problems?

Stephan

5
  1. For convenience we have one queue for each customer. Now if I let
    unpriviledged users see the queues they see all our other customers, too.

So make them privileged. Privileged users do NOT have any rights other than
unprivileged, except the right to get rights. Obviously if you have some
rights assigned to the “Privileged” group, you will have to create another
group (“insiders” or somesuch), put all current users in it, give it the
rights and revoke the rights from “Privileged”.

  1. Very often we have many different people on the customer side reporting and
    dealing with the tickets. So different users need access to the same tickets.
    Thus a solution like “let unprivileged users only access own tickets” is not
    feasible.

My solution now would be to create one group for each customer, putting all
users working for that customer into that group and letting only this group
access the specific customer queue. Ideally customer users, groups an queues
could be generated/synchronized from an existing CRM database.

It should work. As I said, the users need to be privileged (unprivileged
users can’t be members), but that does not give them any rights, so they can
only see what you want them to see.

The synchronization with CRM database should be possible in the hooks
provided for “external authentication”.

					 Jan 'Bulb' Hudec <bulb@ucw.cz>

signature.asc (189 Bytes)

6

Because RT is open
source, if you do this, you have to make the source code available to
everyone. If I could program in perl, I would gladly do it.

Best Regards,
Ravin Mathoora

An important point of order: Open source does not mean that you need
to share private, internal modifications to the software. It does
generally mean that if you distribute your modified version of the
software, you have to let the recipient have the source code AND the
right to change and redistribute what you’ve given them.

There are nuances and disagreements and each opensource license spins
this differently. rt-users isn’t the right forum for a
what-is-opensource discussion, but I did want to be quite explicit that
you are NOT obligated to redistribute internal modifications.

All that being said, the community thrives because people choose to
share their work and I’d strongly encourage you to publish your changes
and extensions to RT.

Best,
Jesse

7

All that being said, the community thrives because people choose to
share their work and I’d strongly encourage you to publish your
changes
and extensions to RT.

I’ve made internal modifications to RT 3.4.2 to not use a table-based
layout, but instead use a CSS based layout. It isn’t XHTML 1.0 Strict
compliant or anything, but it does the job.

You can see a screenshot or two of what I’ve done at:

http://homepage.ntlworld.com/lucysprite/RT/

The alterations weren’t that many in the end, I’ve kept the general
look and feel. Of course I’ve added a couple of custom fields in the
above screenshot, with nice CSS backgrounds (the boss wanted coloured
backgrounds, I gave him coloured backgrounds).

Would people be interested in the modifications I’ve made (took two
days last week, from no prior experience with RT, the ability to
override is very useful, although I’m worried about upgrades to RT
being awkward)? If so, what is the best way to submit modifications?

Also any comments would be appreciated :slight_smile:

Cheers,

Graham

8

All that being said, the community thrives because people choose to
share their work and I’d strongly encourage you to publish your
changes
and extensions to RT.

I’ve made internal modifications to RT 3.4.2 to not use a table-based
layout, but instead use a CSS based layout. It isn’t XHTML 1.0 Strict
compliant or anything, but it does the job.

Oh. We’ve already done this and quite a bit more to switch RT over to an
entirely CSS-based layout in RT 3.5. (3.5.2 is currently available)

I’d love to hear how well the new semantic markup works for you. (And if
you want to contribute another stylesheet for others to use, that’d be
neat, too). There’s still some tweaking going on, but I think we’re
getitng there.

Jesse

9

Hello,

[…]

  1. For convenience we have one queue for each customer. Now if I let
    unpriviledged users see the queues they see all our other customers, too.

We were using the same solutions here, now we use queue for products.

  1. Very often we have many different people on the customer side reporting and
    dealing with the tickets. So different users need access to the same tickets.
    Thus a solution like “let unprivileged users only access own tickets” is not
    feasible.

Our customer are now privileged.

My solution now would be to create one group for each customer, putting all
users working for that customer into that group and letting only this group
access the specific customer queue. Ideally customer users, groups an queues
could be generated/synchronized from an existing CRM database.
Now what I would like to know is, is that a good way to do it? How are other
people dealing with these problems?

Like we create a group for each customer. We put rights on tickets to
requestor and to Cc. The trick is that we put (automagically :slight_smile: ) the
customer group as Cc for each ticket of the customer. Each member of the
group have the right to manipulate (or only see) the ticket.

Each customer will only see his tickets, eac user of the customer group
will see all customer tickets.

I am interested in other answers to this problem too !

Regards,

Florent Manens

fmanens@starxpert.fr

signature.asc (189 Bytes)