Proposed change to RT::Action::CreateTickets::Commit

We are looking into creating approvals using scrips.
The problem is that we notify Administrators that
there is work to be done when a ticket reaches status ‘new’.

To us, status ‘open’ means the ticket is being worked on.

So we have an OnResolve that that changes the work ticket
(a DependedOnBy) from stalled to new.

The problem with doing this with templates is that
RT::Action::CreateTickets::Commit sets the status
to ‘new’ and then changes it to the requested status
after the ticket is created. This is done to avoid
violating dependencies. Thus the admin would
be notified that there is work to do but it can’t
be done yet becuase it hasn’t been approved.

Two possible fixes:

  1. When ticket is created don’t record the transaction.
    Probably not a good idea.

  2. Better idea is to allow setting of status when
    ticket is created if the status is some list
    of values, stalled being the one I would like.

Jesse, would you accept a patch for this behavior?

-Todd

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

We are looking into creating approvals using scrips.
The problem is that we notify Administrators that
there is work to be done when a ticket reaches status ‘new’.

To us, status ‘open’ means the ticket is being worked on.

So we have an OnResolve that that changes the work ticket
(a DependedOnBy) from stalled to new.

The problem with doing this with templates is that
RT::Action::CreateTickets::Commit sets the status
to ‘new’ and then changes it to the requested status
after the ticket is created. This is done to avoid
violating dependencies. Thus the admin would
be notified that there is work to do but it can’t
be done yet becuase it hasn’t been approved.

Two possible fixes:

  1. When ticket is created don’t record the transaction.
    Probably not a good idea.

Definitely not a good idea.

  1. Better idea is to allow setting of status when
    ticket is created if the status is some list
    of values, stalled being the one I would like.

Jesse, would you accept a patch for this behavior?

I’d look at a refactoring that enables this but doesn’t change the
current behaviour by default

Best,
Jesse

-Todd


rt-devel mailing list
rt-devel@lists.bestpractical.com
The rt-devel Archives

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (Darwin)

iD8DBQFAWlzYQaM/s3DrrJARAg/ZAKCqCu4PPpgeFYEpXj8VMT0vI1BVPQCdH82s
WkJs3d7P7KP6lfSnZbU+lH0=
=q9ur
-----END PGP SIGNATURE-----