Opened 4 years ago

Closed 4 years ago

# namespace collision with TracTicketValidator

Reported by: Owned by: solstice333 Ryan J Ollos normal TracTicketValidatorPlugin normal ticket, validation

### Description

On plugin load either TracTicketValidator or TicketValidator is selected making it impossible to use both

### comment:1 Changed 4 years ago by Ryan J Ollos

One option would be to rename this plugin to TicketStateValidator.

### comment:2 Changed 4 years ago by solstice333

I'm okay with the rename. I'm not sure how that affects other users and backwards compatibility though.

### comment:3 follow-up:  7 Changed 4 years ago by solstice333

One thing that's unclear to me is if I'm using both TracTicketValidator and TicketValidator (TicketStateValidator), should I expect TicketValidator to precede TracTicketValidator's validation rules since they both use the [ticketvalidator] section. For example, in trac.ini,

[ticketvalidator]
sha.rule = $[a-f0-9]{8,}/foo_repo$
sha.tip = resolution SHA requires formatting syntax of "[<sha>/foo_repo]" where <sha> is replaced with a SHA of 8 characters or more
closed.required = sha


which I believe the semantics are -- on the closed state, require the sha field, and require the sha field to be of valid syntax for SHA and changeset traclink. Otherwise, on every other state, ignore all requirements for the sha field.

Maybe this is slightly out of scope of the ticket description though....

Last edited 4 years ago by solstice333 (previous) (diff)

### comment:4 Changed 4 years ago by Ryan J Ollos

r7518 claims to have resolved the issue. Investigating ...

### comment:5 Changed 4 years ago by Ryan J Ollos

Component: TicketValidatorPlugin → TracTicketValidatorPlugin set to Ryan J Ollos new → accepted

### comment:6 Changed 4 years ago by Ryan J Ollos

Resolution: → fixed accepted → closed

In 17105:

TracTicketValidator 0.3: Avoid package namespace collision

Change package name to avoid collision with TicketValidatorPlugin.

The new component rule is:

tracticketvalidator.ticketvalidator.*


or

tracticketvalidator.*


Fixes #13406.

### comment:7 in reply to:  3 ; follow-up:  8 Changed 4 years ago by Ryan J Ollos

One thing that's unclear to me is if I'm using both TracTicketValidator and TicketValidator (TicketStateValidator), should I expect TicketValidator to precede TracTicketValidator's validation rules since they both use the [ticketvalidator] section.

The option names don't overlap, so it doesn't appear to be a problem that the plugins use the same section name. The order in which ITicketManipulators are called in not defined, however any of the implementers can reject the ticket change.

It appears that sha.rule will need to be satisfied for every ticket state.

I think it would be good to eventually merge the two plugins together, but not sure when I will have time to work on that.

### comment:8 in reply to:  7 Changed 4 years ago by solstice333

One thing that's unclear to me is if I'm using both TracTicketValidator and TicketValidator (TicketStateValidator), should I expect TicketValidator to precede TracTicketValidator's validation rules since they both use the [ticketvalidator] section.

The option names don't overlap, so it doesn't appear to be a problem that the plugins use the same section name. The order in which ITicketManipulators are called in not defined, however any of the implementers can reject the ticket change.

It appears that sha.rule will need to be satisfied for every ticket state.

I think it would be good to eventually merge the two plugins together, but not sure when I will have time to work on that.

No worries. I don't think it's too big of a deal for me at the moment. I was able to settle with using tracticketvalidatorplugin for validation in combination with a slightly customized version of keepinterfacesimpleplugin to conditionally hide fields. Thanks for looking into it.

### Modify Ticket

Change Properties