Howdy,
When I change a tickets queue, it loses it’s keywords, even if the new queue
has the same keyword lists!?
Stuart
When I change a tickets queue, it loses it’s keywords, even if the new queue
has the same keyword lists!?
I think this is correct behavior.
Somebody correct me if I’m wrong:
- A queue has tickets
- A queue can have keywords
- The keywords in a queue can be assigned to a ticket in that queue
- A queue change of a ticket loses all keywords, because the keywords
were connected to the other queue. If the other queue has the same
keywords or not is irrelevant.
Martin
Martin Schapendonk, martin@schapendonk.org, Phone: +31 (0)6 55770237
Student Information Systems and Management at Tilburg University
Hi There!
There should be a possibility to have a certain data-structure (e.g. a MySQK
table) that holds a set of “global” keywords which can be connected to a
ticket as the queue specific keywords can.
I don’t know how to implement it as i haven’t had the time to go through the
code of RT, but I have done a similar thing in one of the projects I worked
on (www.formular25.de).
Concerning the structure of the relation between keywords and tickets it
should be an n:m relation, whicht should be no problem to handle with a
junction entity.
Nevertheless I don’t know how useful this feature would be.
By the way I don’t know how useful this mail is…
Regards,
Benjamin Boksa> On Fri, 14 Sep 2001, Stuart Campbell wrote:
When I change a tickets queue, it loses it’s keywords, even if the new queue
has the same keyword lists!?
I think this is correct behavior.
Somebody correct me if I’m wrong:
- A queue has tickets
- A queue can have keywords
- The keywords in a queue can be assigned to a ticket in that queue
- A queue change of a ticket loses all keywords, because the keywords
were connected to the other queue. If the other queue has the same
keywords or not is irrelevant.Martin
Benjamin Boksa
b.boksa@sidebysite.de
side by site GmbH & Co. KG
Druckgestaltung & Webdesign
Barbarastr. 3-9 (Block 6)
D-50735 Koeln
Telefon: +49 221 2790964
Telefax: +49 221 2790965
Hi There!
There should be a possibility to have a certain data-structure (e.g. a MySQK
table) that holds a set of “global” keywords which can be connected to a
ticket as the queue specific keywords can.
I don’t know how to implement it as i haven’t had the time to go through the
code of RT, but I have done a similar thing in one of the projects I worked
on (www.formular25.de).
Concerning the structure of the relation between keywords and tickets it
should be an n:m relation, whicht should be no problem to handle with a
junction entity.
Nevertheless I don’t know how useful this feature would be.
By the way I don’t know how useful this mail is…
Regards,
Benjamin Boksa> On Fri, 14 Sep 2001, Stuart Campbell wrote:
When I change a tickets queue, it loses it’s keywords, even if the new queue
has the same keyword lists!?
I think this is correct behavior.
Somebody correct me if I’m wrong:
- A queue has tickets
- A queue can have keywords
- The keywords in a queue can be assigned to a ticket in that queue
- A queue change of a ticket loses all keywords, because the keywords
were connected to the other queue. If the other queue has the same
keywords or not is irrelevant.Martin
Benjamin Boksa
b.boksa@sidebysite.de
side by site GmbH & Co. KG
Druckgestaltung & Webdesign
Barbarastr. 3-9 (Block 6)
D-50735 Koeln
Telefon: +49 221 2790964
Telefax: +49 221 2790965
Martin Schapendonk writes:> On Fri, 14 Sep 2001, Stuart Campbell wrote:
When I change a tickets queue, it loses it’s keywords, even if the new queue
has the same keyword lists!?
I think this is correct behavior.
Just my $0.02…
This behavior makes it a little harder to do escalation between different
queues. For example, I want to have a triage queue that has one set of
people on it, and if they can’t solve the problem, they transfer the ticket
to a different queue for a different set of people to work on. This is
handled nicely with the AdminCC having a per-queue context, but if the
keywords are lost, it means that for tracking purposes the new queue
members need to re-enter them.
It would be nice if any shared keyword selections are preserved, but the
rest are set to empty values.
-Matt
This is very close to how I am trying to use RT.
There are different groups of people who at different times could be
responsible for responding to tickets. Generally, tickets that one group is
assigned should not be accessed by another group.
The reason I set up multiple queues is because it’s not possible to apply
group rights to individual tickets, or groups of tickets within a single
queue. That is, i f a user can access one ticket in a queue, that user can
access any ticket in that queue (unless I’m missing something?)
Although keywords are configured per queue, I think logically, keywords are
more a property of tickets, since they enhance a problem/ticket description.
For a ticket to lose some of it’s properties when it’s moved doesnt make
sense.
Once again, I’m not trying to be critical, I’m just trying to work out how
RT works, and how it can work in my situation.
Regards,
StuartFrom: Matthew D. Stock [mailto:stock@cse.Buffalo.EDU]
Sent: Friday, 14 September 2001 23:43
To: Martin Schapendonk
Cc: Stuart Campbell; rt-users@lists.fsck.com
Subject: Re: [rt-users] Possible bug with keywords
Martin Schapendonk writes:
When I change a tickets queue, it loses it’s keywords, even if the new
queue
has the same keyword lists!?
I think this is correct behavior.
Just my $0.02…
This behavior makes it a little harder to do escalation between different
queues. For example, I want to have a triage queue that has one set of
people on it, and if they can’t solve the problem, they transfer the ticket
to a different queue for a different set of people to work on. This is
handled nicely with the AdminCC having a per-queue context, but if the
keywords are lost, it means that for tracking purposes the new queue
members need to re-enter them.
It would be nice if any shared keyword selections are preserved, but the
rest are set to empty values.
-Matt