Bug? Imbalance in linking history

When you linkg 2 tickets or delete a link between 2 tickets,
the transaction is only recorded in the ticket that is
used to add/delete the link. Given the bi-directional
nature of links, shouldn’t these transaction be recorded
in both tickets?

-Todd

When you linkg 2 tickets or delete a link between 2 tickets,
the transaction is only recorded in the ticket that is
used to add/delete the link. Given the bi-directional
nature of links, shouldn’t these transaction be recorded
in both tickets?

Should it generate two transactions? (and run two sets of scrips…)

This was something I angsted about at the time, but I haven’t heard much
in the way of commentary about it until now.

Jesse

When you linkg 2 tickets or delete a link between 2 tickets,
the transaction is only recorded in the ticket that is
used to add/delete the link. Given the bi-directional
nature of links, shouldn’t these transaction be recorded
in both tickets?

Should it generate two transactions? (and run two sets of scrips…)

This was something I angsted about at the time, but I haven’t heard much
in the way of commentary about it until now.

I would think that it should generate two transactions but have
one of them supress running scrips. Anyone writing s scrip based
on adding/deleting scrips should expect one transaction and look
at both ends of the link. Well, look at both ends of the link
for AddLink. Of the top of my head I’m not sure how to find both
ends of the link for DeleteLink. Unless deleting a link
should cause 2 scrips to run. Either way both tickets should
have a transaction; I’m sure of that.

I would like to see two transactions as well, but have them be different
– base and target for example. Then we can queue the scrips off the
different ends.

Joby Walker
ITI SSG, University of Washington

Todd Chapman wrote:> On Thu, Nov 03, 2005 at 04:30:01PM -0500, Jesse Vincent wrote:

On Thu, Nov 03, 2005 at 04:04:00PM -0500, Todd Chapman wrote:

When you linkg 2 tickets or delete a link between 2 tickets,
the transaction is only recorded in the ticket that is
used to add/delete the link. Given the bi-directional
nature of links, shouldn’t these transaction be recorded
in both tickets?

Should it generate two transactions? (and run two sets of scrips…)

This was something I angsted about at the time, but I haven’t heard much
in the way of commentary about it until now.

I would think that it should generate two transactions but have
one of them supress running scrips. Anyone writing s scrip based
on adding/deleting scrips should expect one transaction and look
at both ends of the link. Well, look at both ends of the link
for AddLink. Of the top of my head I’m not sure how to find both
ends of the link for DeleteLink. Unless deleting a link
should cause 2 scrips to run. Either way both tickets should
have a transaction; I’m sure of that.

Jesse

-Todd


Rt-devel mailing list
Rt-devel@lists.bestpractical.com
http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-devel


Rt-devel mailing list
Rt-devel@lists.bestpractical.com
http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-devel

This was something I angsted about at the time, but I haven’t heard much
in the way of commentary about it until now.

I would think that it should generate two transactions but have
one of them supress running scrips. Anyone writing s scrip based
on adding/deleting scrips should expect one transaction and look
at both ends of the link. Well, look at both ends of the link
for AddLink. Of the top of my head I’m not sure how to find both
ends of the link for DeleteLink. Unless deleting a link
should cause 2 scrips to run. Either way both tickets should
have a transaction; I’m sure of that.

What should the generic OnTransaction scrip do?

This was something I angsted about at the time, but I haven’t heard much
in the way of commentary about it until now.

I would think that it should generate two transactions but have
one of them supress running scrips. Anyone writing s scrip based
on adding/deleting scrips should expect one transaction and look
at both ends of the link. Well, look at both ends of the link
for AddLink. Of the top of my head I’m not sure how to find both
ends of the link for DeleteLink. Unless deleting a link
should cause 2 scrips to run. Either way both tickets should
have a transaction; I’m sure of that.

What should the generic OnTransaction scrip do?

I don’t follow you. ???

I would think that it should generate two transactions but have
one of them supress running scrips.

Anyone writing s scrip based
on adding/deleting scrips should expect one transaction and look
at both ends of the link. Well, look at both ends of the link
for AddLink. Of the top of my head I’m not sure how to find both
ends of the link for DeleteLink. Unless deleting a link
should cause 2 scrips to run. Either way both tickets should
have a transaction; I’m sure of that.

What should the generic OnTransaction scrip do?

I don’t follow you. ???

Terribly sorry. I missed the underlined phrase. Wanna send a patch and
tests? :wink:

+1 about two transactions

But IMO we should run scrips twice, reasons:

  1. would be consistent solution, as less exceptions we have as more
    maintainable and refactorable our code is;
  2. scrip in normal stage must have three context objects: ticket,
    transaction, template; if you run scrips only for one transaction then
    authors of the scrips have to dig additional context objects themself
    which leads to new questions on the rt-users.
  3. previouse behaviour is bug and if scrips follow buggy behaviour
    then them should be changed;
  4. …On 11/4/05, Jesse Vincent jesse@bestpractical.com wrote:

I would think that it should generate two transactions but have
one of them supress running scrips.

  __________________________________

Anyone writing s scrip based
on adding/deleting scrips should expect one transaction and look
at both ends of the link. Well, look at both ends of the link
for AddLink. Of the top of my head I’m not sure how to find both
ends of the link for DeleteLink. Unless deleting a link
should cause 2 scrips to run. Either way both tickets should
have a transaction; I’m sure of that.

What should the generic OnTransaction scrip do?

I don’t follow you. ???

Terribly sorry. I missed the underlined phrase. Wanna send a patch and
tests? :wink:


Rt-devel mailing list
Rt-devel@lists.bestpractical.com
http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-devel

Best regards, Ruslan.

+1 about two transactions

But IMO we should run scrips twice, reasons:

  1. would be consistent solution, as less exceptions we have as more
    maintainable and refactorable our code is;
  2. scrip in normal stage must have three context objects: ticket,
    transaction, template; if you run scrips only for one transaction then
    authors of the scrips have to dig additional context objects themself
    which leads to new questions on the rt-users.
  3. previouse behaviour is bug and if scrips follow buggy behaviour
    then them should be changed;

One scrip / two scrips, I’m not sure. What do you think Jesse? I
don’t want to think about working on a patch unless there is
some agreement.

Todd Chapman wrote:> On Fri, Nov 04, 2005 at 01:36:39AM +0300, Ruslan Zakirov wrote:

+1 about two transactions

But IMO we should run scrips twice, reasons:

  1. would be consistent solution, as less exceptions we have as more
    maintainable and refactorable our code is;
  2. scrip in normal stage must have three context objects: ticket,
    transaction, template; if you run scrips only for one transaction then
    authors of the scrips have to dig additional context objects themself
    which leads to new questions on the rt-users.
  3. previouse behaviour is bug and if scrips follow buggy behaviour
    then them should be changed;

One scrip / two scrips, I’m not sure. What do you think Jesse? I
don’t want to think about working on a patch unless there is
some agreement.

If I may voice an opinion here, I also think that for the sake of
consistency, scrips should be run for every transaction.

I can, however, think of another solution to the missing transaction:
Make the depended-on-by and referred-to-by fields either display-only or
have them create the transaction on the target object. That way it’s
clear that the transaction is always on the originating end of the referral.

Rolf.

If I may voice an opinion here, I also think that for the sake of
consistency, scrips should be run for every transaction.

I can, however, think of another solution to the missing transaction:
Make the depended-on-by and referred-to-by fields either display-only or
have them create the transaction on the target object. That way it’s
clear that the transaction is always on the originating end of the referral.

I don’t quite understand. Display-only? The links are tracked in a table
al their own.

Todd Chapman wrote:

+1 about two transactions

But IMO we should run scrips twice, reasons:

  1. would be consistent solution, as less exceptions we have as more
    maintainable and refactorable our code is;
  2. scrip in normal stage must have three context objects: ticket,
    transaction, template; if you run scrips only for one transaction then
    authors of the scrips have to dig additional context objects themself
    which leads to new questions on the rt-users.
  3. previouse behaviour is bug and if scrips follow buggy behaviour
    then them should be changed;

One scrip / two scrips, I’m not sure. What do you think Jesse? I
don’t want to think about working on a patch unless there is
some agreement.

If I may voice an opinion here, I also think that for the sake of
consistency, scrips should be run for every transaction.

I can, however, think of another solution to the missing transaction:
Make the depended-on-by and referred-to-by fields either display-only or
have them create the transaction on the target object. That way it’s
clear that the transaction is always on the originating end of the referral.

That seems to imply that one end of the link is more important than the other,
and I don’t think that’s the case. Base and Target are just conventions, and
it could have easily been reversed.

If I may voice an opinion here, I also think that for the sake of
consistency, scrips should be run for every transaction.

I can, however, think of another solution to the missing transaction:
Make the depended-on-by and referred-to-by fields either display-only or
have them create the transaction on the target object. That way it’s
clear that the transaction is always on the originating end of the referral.

I don’t quite understand. Display-only? The links are tracked in a table
al their own.

He means to make it so you can only delete a link from the Base ticket
and not the Target. See my other response…

+1 about two transactions

But IMO we should run scrips twice, reasons:

  1. would be consistent solution, as less exceptions we have as more
    maintainable and refactorable our code is;
  2. scrip in normal stage must have three context objects: ticket,
    transaction, template; if you run scrips only for one transaction then
    authors of the scrips have to dig additional context objects themself
    which leads to new questions on the rt-users.
  3. previouse behaviour is bug and if scrips follow buggy behaviour
    then them should be changed;

My reply to this seems to be lost so at the risk of repeating myself:

The thing that concerns me about two scrips is, what if you
want to send an e-mail on AddLink, but you only want to do
it once. How do you make the two scrips aware of each other
so that only one performs the action? If there is a simple
solution to this problem, then 2 scrips is fine wiht me.
Otherwise I think it’s better to have one scrip run and
the user and figure out what object was at the other end.

-Todd

Todd Chapman wrote:

That seems to imply that one end of the link is more important than
the other, and I don’t think that’s the case. Base and Target are just
conventions, and it could have easily been reversed.

I’m not quite sure I follow. The conventions have been chosen, so why
not use them?

The thing that concerns me about two scrips is, what if you
want to send an e-mail on AddLink, but you only want to do
it once. How do you make the two scrips aware of each other
so that only one performs the action? If there is a simple
solution to this problem, then 2 scrips is fine wiht me.
Otherwise I think it’s better to have one scrip run and
the user and figure out what object was at the other end.

You can tell from the transaction’s Field property what is being
changed. Right now, you’d probably run the scrip for every AddLink
transaction, and you have to figure out whether it’s for the Base or the
Target side of the link. If we run scrips for both objects (since both
should have the transaction), you would only run the scrip for the base
or the target object or the right Field type (e.g. only RefersTo not
ReferredToBy). Is there a problem with that which I’m missing?

The more I think about it, two transactions are probably the better
solution. Right now, the transaction is recorded depending on where the
user makes the change. Since linking always involves two objects, there
should be a transaction for both of them. And since a transaction
invokes scrips, two sets of scrips will be run. What’s new then, is that
one operation by the user can result in two transactions. Shouldn’t be a
problem, right?

Rolf.

Todd Chapman wrote:

My reply to this seems to be lost so at the risk of repeating myself:

The thing that concerns me about two scrips is, what if you
want to send an e-mail on AddLink, but you only want to do
it once. How do you make the two scrips aware of each other
so that only one performs the action? If there is a simple
solution to this problem, then 2 scrips is fine wiht me.
Otherwise I think it’s better to have one scrip run and
the user and figure out what object was at the other end.

-Todd

The problem is that you might want to send two emails. If the Sales
queue links one of their tickets (say #2) to a ticket (#4) as DependsOn
in the Support queue. There are two descrete actions that should happen:

  1. the Sales ticket (#2) might notify a set of people that the ticket is
    blocked.

  2. the Support ticket (#4) might notify a set of people that it is
    blocking another ticket.

Joby Walker
ITI SSG, University of Washington

Todd Chapman wrote:

That seems to imply that one end of the link is more important than
the other, and I don’t think that’s the case. Base and Target are just
conventions, and it could have easily been reversed.

I’m not quite sure I follow. The conventions have been chosen, so why
not use them?

There just conventions. One end of the link is no more important
than the other.

The thing that concerns me about two scrips is, what if you
want to send an e-mail on AddLink, but you only want to do
it once. How do you make the two scrips aware of each other
so that only one performs the action? If there is a simple
solution to this problem, then 2 scrips is fine wiht me.
Otherwise I think it’s better to have one scrip run and
the user and figure out what object was at the other end.

You can tell from the transaction’s Field property what is being
changed. Right now, you’d probably run the scrip for every AddLink
transaction, and you have to figure out whether it’s for the Base or the
Target side of the link. If we run scrips for both objects (since both
should have the transaction), you would only run the scrip for the base
or the target object or the right Field type (e.g. only RefersTo not
ReferredToBy). Is there a problem with that which I’m missing?

The more I think about it, two transactions are probably the better
solution. Right now, the transaction is recorded depending on where the
user makes the change. Since linking always involves two objects, there
should be a transaction for both of them. And since a transaction
invokes scrips, two sets of scrips will be run. What’s new then, is that
one operation by the user can result in two transactions. Shouldn’t be a
problem, right?

Would it be more common to want an AddLink scrip to run once, or
twice (for each end of the link)? Whichever is more common, make
that the default.

Todd Chapman wrote:

My reply to this seems to be lost so at the risk of repeating myself:

The thing that concerns me about two scrips is, what if you
want to send an e-mail on AddLink, but you only want to do
it once. How do you make the two scrips aware of each other
so that only one performs the action? If there is a simple
solution to this problem, then 2 scrips is fine wiht me.
Otherwise I think it’s better to have one scrip run and
the user and figure out what object was at the other end.

-Todd

The problem is that you might want to send two emails. If the Sales
queue links one of their tickets (say #2) to a ticket (#4) as DependsOn
in the Support queue. There are two descrete actions that should happen:

  1. the Sales ticket (#2) might notify a set of people that the ticket is
    blocked.

  2. the Support ticket (#4) might notify a set of people that it is
    blocking another ticket.

And you could do that from one scrip.

If we could imagine what the most common use cases would be I
would optize for that. If we are not sure in out ability to
guess the most common case then 2 scrips is probably the
way to go.

+1 about two transactions

But IMO we should run scrips twice, reasons:

  1. would be consistent solution, as less exceptions we have as more
    maintainable and refactorable our code is;
  2. scrip in normal stage must have three context objects: ticket,
    transaction, template; if you run scrips only for one transaction then
    authors of the scrips have to dig additional context objects themself
    which leads to new questions on the rt-users.
  3. previouse behaviour is bug and if scrips follow buggy behaviour
    then them should be changed;

My reply to this seems to be lost so at the risk of repeating myself:

The thing that concerns me about two scrips is, what if you
want to send an e-mail on AddLink, but you only want to do
it once. How do you make the two scrips aware of each other
so that only one performs the action? If there is a simple
solution to this problem, then 2 scrips is fine wiht me.
Otherwise I think it’s better to have one scrip run and
the user and figure out what object was at the other end.

What if the linking/delinking operation is performed first, then scrips
executed on the resultant ticket(s)?

–j, very likely missing something.
Jim Meyer, Geek at Large purp@selequa.com

Todd Chapman wrote:

The problem is that you might want to send two emails. If the Sales
queue links one of their tickets (say #2) to a ticket (#4) as DependsOn
in the Support queue. There are two descrete actions that should happen:

  1. the Sales ticket (#2) might notify a set of people that the ticket is
    blocked.

  2. the Support ticket (#4) might notify a set of people that it is
    blocking another ticket.

And you could do that from one scrip.

You could, but I’d argue that it was bad practice. It should be the
Support queue scrips that determine actions on link creation/deletion
for tickets in the Support queue, and the Sales queue scrips to do the
same for tickets in the Sales queue.

If you have a large organization like me, It is very hard to get
consensus on global scrip behavior. One group would want a new block to
send email, another would want a priority escalation, a third would want
both, and a fourth would want no action. To do this in global scrips
would be insane – and queue based scrips shouldn’t need to take into
account the preferences of another queue.

If we could imagine what the most common use cases would be I
would optize for that. If we are not sure in out ability to
guess the most common case then 2 scrips is probably the
way to go.

The only way to allow for the customization above would be to have 2
transactions.

Joby Walker
ITI SSG, University of Washington