Restricting a Merge

RT Users
1

We have a custom field for Client Name. I’d really like it so that two
tickets can’t be merged unless they both have the same value for this
field, as we’ve had a couple of cases of merging the wrong tickets
accidentally, and this would provide another useful level of sanity
checking on that.

My guess is that I want to write a scrip for this, but I haven’t added
anything like this before. Before I get stuck into learning about that,
is that the direction I should be heading in? Is there an example
somewhere that I’ve missed for doing this sort of thing?

I’m fairly new to adminning an RT set-up: we had Simon around to do this
for us before :slight_smile:

Thanks,

Tony

2

We have a custom field for Client Name. I’d really like it so that two
tickets can’t be merged unless they both have the same value for this
field, as we’ve had a couple of cases of merging the wrong tickets
accidentally, and this would provide another useful level of sanity
checking on that.

My guess is that I want to write a scrip for this, but I haven’t added
anything like this before. Before I get stuck into learning about that,
is that the direction I should be heading in? Is there an example
somewhere that I’ve missed for doing this sort of thing?

Actually, it sounds like you’d want to overlay or Hook::LexWrap
RT::Ticket_Overlay.pm’s
MergeInto subroutine.

Precondition/Validation scrips are something I’d love to do, but not
there yet.

I’m fairly new to adminning an RT set-up: we had Simon around to do
this
for us before :slight_smile:

Heh. Welcome.

Jesse

3

Actually, it sounds like you’d want to overlay or Hook::LexWrap
RT::Ticket_Overlay.pm’s MergeInto subroutine.
Precondition/Validation scrips are something I’d love to do, but not
there yet.

OK. I’ll look into that, then.

I’m fairly new to adminning an RT set-up: we had Simon around to do
this for us before :slight_smile:
Heh. Welcome.

I’m getting there. I’m fairly comfortable with switching in my own
templates, although Mason seems really clumsy to me (I’m a TT user
usually).

I’ve a few other problems that I’ll be sending through separately.

Thanks,

Tony

4

Actually, it sounds like you’d want to overlay or Hook::LexWrap
RT::Ticket_Overlay.pm’s
MergeInto subroutine.
Precondition/Validation scrips are something I’d love to do, but not
there yet.

That’s one BIG method to overlay.

Is it possible for it to either be split up? Perhaps we could have all
the early checks split out canMergeInto() or somesuch?

I could supply a patch if you want, but it looks like it’s just a matter
of extracting everything from
unless ($self->CurrentUserHasRight(‘ModifyTicket’)
down to the comment about using EffectiveID out.

Of course for extra bonus marks each check would be its own method so that
people can override the behaviour in a much more fine grained manner. :slight_smile:

Tony

5

Actually, it sounds like you’d want to overlay or Hook::LexWrap
RT::Ticket_Overlay.pm’s
MergeInto subroutine.
Precondition/Validation scrips are something I’d love to do, but not
there yet.

That's one BIG method to overlay.

Yeah, it could definitely use a bunch of refactoring. I’ll certainly look at a proposed factoring and give commentary

Of course for extra bonus marks each check would be its own method so that
people can override the behaviour in a much more fine grained manner. :)

Yeah. That doesn’t sound like a bad plan at all, though I start to wonder if there’s a better pattern for all this.
Jesse