RT3.8beta - creating child tickets

In the Links section of the new interface for RT3.8beta, there are
"Create" links next to each link type. This seems to imply that if I
click the “Create” link next to the Children label, and then fill out
the ticket information, I would get a new child ticket.

However, it actually creates a parent ticket. This seems backwards.

The other links are also backward in my mind. Instead of making the new
ticket appear where I clicked “create”, it makes the new ticket appear
at the opposite link.

Is this intentional? Am I the only one finding this counter-intuitive?
Jason

It is indeed messed up. I’ve got a patch I just put together to
hopefully smooth it out.

Best,
JesseOn May 5, 2008, at 2:17 PM, Jason Long wrote:

In the Links section of the new interface for RT3.8beta, there are
"Create" links next to each link type. This seems to imply that if I
click the “Create” link next to the Children label, and then fill out
the ticket information, I would get a new child ticket.

However, it actually creates a parent ticket. This seems backwards.

The other links are also backward in my mind. Instead of making the
new
ticket appear where I clicked “create”, it makes the new ticket appear
at the opposite link.

Is this intentional? Am I the only one finding this counter-intuitive?
Jason


List info: http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-devel

PGP.sig (186 Bytes)

Thanks, my one major complaint about this feature has been fixed.

Another bug. The newly created ticket copies the links from the original
ticket. This may be the way it was designed, but it leads to undesirable
results.

Create a ticket.
Click Children->Create to create a child ticket.
So far so good.

Go back to the first ticket, and click Children->Create to make a second
child ticket.
Go back to the original ticket, and see what happened.

It created some sort of infinite loop between the two child tickets…
kind of hard to explain, I’m hoping you’ll be able to see it for yourself.

Frankly, when I create a ticket through the Links screen, I don’t think
it should copy all attributes from the origin ticket. Perhaps the
subject, and maybe the watchers, should be copied, but definitely don’t
copy the links.

Jason

Jesse Vincent wrote:

Thanks, my one major complaint about this feature has been fixed.

Another bug. The newly created ticket copies the links from the
original ticket. This may be the way it was designed, but it leads
to undesirable results.

I’d love to hear some more folks input on this one. It’s certainly
working as “designed”. The infinite loop behavior feels clearly wrong.
But what about the rest of the cloning behavior? I’d like to get this
nailed down in the next week or two.

So. If you’re reading this and have an opinion or a use case, please
chime in.

Jesse

PGP.sig (186 Bytes)

Thanks, my one major complaint about this feature has been fixed.

Another bug. The newly created ticket copies the links from the
original ticket. This may be the way it was designed, but it leads
to undesirable results.

I’d love to hear some more folks input on this one. It’s certainly
working as “designed”. The infinite loop behavior feels clearly
wrong. But what about the rest of the cloning behavior? I’d like to
get this nailed down in the next week or two.

So. If you’re reading this and have an opinion or a use case, please
chime in.

For what it’s worth, my opinion : status, priority, queue, custom
fields, reminders/Dates, and people, should be cloned, but not the
links.

Actually, couldn’t the behavior be configurable ? (maybe it is
already, in this case just ignore me)

dams

Jesse

Create a ticket.
Click Children->Create to create a child ticket.
So far so good.

Go back to the first ticket, and click Children->Create to make a
second child ticket.
Go back to the original ticket, and see what happened.

It created some sort of infinite loop between the two child
tickets… kind of hard to explain, I’m hoping you’ll be able to
see it for yourself.

Frankly, when I create a ticket through the Links screen, I don’t
think it should copy all attributes from the origin ticket.
Perhaps the subject, and maybe the watchers, should be copied, but
definitely don’t copy the links.

Jason

Jesse Vincent wrote:

It is indeed messed up. I’ve got a patch I just put together to
hopefully smooth it out.

Best,
Jesse

In the Links section of the new interface for RT3.8beta, there are
"Create" links next to each link type. This seems to imply that
if I click the “Create” link next to the Children label, and then
fill out
the ticket information, I would get a new child ticket.

However, it actually creates a parent ticket. This seems
backwards.

The other links are also backward in my mind. Instead of making
the new
ticket appear where I clicked “create”, it makes the new ticket
appear
at the opposite link.

Is this intentional? Am I the only one finding this counter-
intuitive?
Jason

dams

Jesse Vincent wrote:

I’d love to hear some more folks input on this one. It’s certainly
working as “designed”. The infinite loop behavior feels clearly wrong.
But what about the rest of the cloning behavior? I’d like to get this
nailed down in the next week or two.

So. If you’re reading this and have an opinion or a use case, please
chime in.

I would rather have these “Create” buttons serve as a “create a related
ticket” rather than a “clone this ticket” feature. Perhaps there could
be an additional button there, “Clone Ticket” which copies everything
(including links), but does not establish any relationship between the
tickets.

When I “create a related ticket”, I would like it to copy the subject
and maybe the watchers and priority from the original ticket, but pretty
much nothing else.

Here’s my fun example. I’m working on ticket #2- “bake a cake”. I
determine that I don’t have enough flour on hand. I create a "child"
ticket #3- “get more flour”. The child ticket #3 could be in a separate
queue, assigned to someone else. I, the owner of #2, am the requester of
#3. Someone else can take #3, perform the task, and I’ll be notified
when it is completed.

Jason

When I “create a related ticket”, I would like it to copy the subject
and maybe the watchers and priority from the original ticket, but pretty
much nothing else.

The most common use case we’ve run into is “user included two issues in
one ticket.”

Here’s my fun example. I’m working on ticket #2- “bake a cake”. I
determine that I don’t have enough flour on hand. I create a "child"
ticket #3- “get more flour”. The child ticket #3 could be in a separate
queue, assigned to someone else. I, the owner of #2, am the requester of
#3. Someone else can take #3, perform the task, and I’ll be notified
when it is completed.

Given that I don’t think you’re using RT for cake processing (though I’d
love to hear about it if you are), what do you have for real-world usage
examples? I’m specifically looking for non-contrived situations to help
inform the design :wink:

-j

This is actually a pretty common scenario, I can put it technical
context.

I have a ticket to install a new customers website in our group. I go to
the server I’m going to install it on, and realize that I don’t have
enough disk space to satisfy the install. I’ll than create child ticket
to the infrastructure team requesting they had 20gb of space to that web
server.

Justin BrodleyFrom: rt-devel-bounces@lists.bestpractical.com
[mailto:rt-devel-bounces@lists.bestpractical.com] On Behalf Of Jesse
Vincent
Sent: Monday, May 12, 2008 9:15 AM
To: Jason Long
Cc: RT developers
Subject: Re: [Rt-devel] POLL Re: RT3.8beta - creating child tickets

When I “create a related ticket”, I would like it to copy the subject
and maybe the watchers and priority from the original ticket, but
pretty
much nothing else.

The most common use case we’ve run into is “user included two issues in
one ticket.”

Here’s my fun example. I’m working on ticket #2- “bake a cake”. I
determine that I don’t have enough flour on hand. I create a "child"
ticket #3- “get more flour”. The child ticket #3 could be in a
separate
queue, assigned to someone else. I, the owner of #2, am the requester
of
#3. Someone else can take #3, perform the task, and I’ll be notified
when it is completed.

Given that I don’t think you’re using RT for cake processing (though I’d
love to hear about it if you are), what do you have for real-world usage
examples? I’m specifically looking for non-contrived situations to help
inform the design :wink:

-j

Jason

List info:
http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-devel

Jesse Vincent wrote:

Given that I don’t think you’re using RT for cake processing (though I’d
love to hear about it if you are), what do you have for real-world usage
examples? I’m specifically looking for non-contrived situations to help
inform the design :wink:

Heh :). Well, Justin gave a pretty good example… My "real-world"
example is similar to his.

On Feb 13, I took ticket #12414, which requested a server for hosting
APEX-based applications. I setup a new virtual machine, installed an OS,
assigned it an IP address, etc. Then I created a few “child” tickets.
The first child ticket, #12905, was put in our “networking” queue, and
it asked that the firewall be configured to allow HTTP access from
anywhere to this server. The second child ticket, #12906, asked for an
SSL certificate to be purchased and installed on this new server. The
third child ticket, created some time later, #13048, asked for our
backup server administrator to add this server to a regularly-scheduled
backup job.

The three child tickets each had unique subjects, were assigned to
differing persons, and were started/completed at different times. They
all had myself as the requester. None of the tickets used any custom
fields, nor did we assign a value to the priority field, so not sure
what makes sense there.

Jason

We have the same two issues per ticket problem, but we do also create
child tickets for new calls / purchases that need to happen. If we have
a ticket to install a new computer and the network port isn’t live, we
like to make a child ticket to connect it in the network closet, since
installing a computer and plugging in some patch cable aren’t related
enough to live on the same ticket. Similarly if a user needs some
software installed which has yet to be purchased, we create a child
ticket in a purchasing queue so that the purchasing person will get a
license before we go back and install.On my to do list right now are a ‘Spawn Call’ and ‘Spawn Purchase’ button for 3.6, but I rarely get time to work on things like that. Andrew Redman Gevirtz Graduate School of Education, UCSB Jesse Vincent wrote:

When I “create a related ticket”, I would like it to copy the subject
and maybe the watchers and priority from the original ticket, but pretty
much nothing else.

The most common use case we’ve run into is “user included two issues in
one ticket.”

Here’s my fun example. I’m working on ticket #2- “bake a cake”. I
determine that I don’t have enough flour on hand. I create a "child"
ticket #3- “get more flour”. The child ticket #3 could be in a separate
queue, assigned to someone else. I, the owner of #2, am the requester of
#3. Someone else can take #3, perform the task, and I’ll be notified
when it is completed.

Given that I don’t think you’re using RT for cake processing (though I’d
love to hear about it if you are), what do you have for real-world usage
examples? I’m specifically looking for non-contrived situations to help
inform the design :wink:

-j

Jason

We have one queue for customer support issues and one queue for product
issues. Often, while diagnosing a customer support issue a linked
product issue ticket is created. Sometimes this step is forgotten and
the entire investigation of the product issue is recorded on the
customer support ticket. In these cases it would be useful to clone the
customer support ticket, with all custom fields and links etc, into the
product issues queue, and link the two tickets together.

Gordon