namespace collision with TracTicketValidator

[solstice333]

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

[Ryan J Ollos]

One option would be to rename this plugin to TicketStateValidator.

[solstice333]

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

[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-fA-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....

[Ryan J Ollos]

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

[Ryan J Ollos]

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.

[Ryan J Ollos]

Replying to 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.

[solstice333]

Replying to Ryan J Ollos:

Replying to 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.