Disable setting null-milestone

[franz.mayer@…]

A ticket should always have a milestone (at least in our installation). So setting milestone to null is not an option.

My suggestion would be that if there is configurated a default milestone, the milestone null shouldn't be in the milestone list.

[osimons]

The ability to modify and validate according to the rules you need is a major reason for why we have a ticket API. Here is a ~10 code lines plugin that will disallow ticket edits where milestone is not set:

from trac.core import Component, implements
from trac.ticket.api import ITicketManipulator

class RequireMilestone(Component):

    implements(ITicketManipulator)

    def prepare_tickett(self, req, ticket, fields, actions):
        pass

    def validate_ticket(self, req, ticket):
        if not ticket['milestone']:
            yield ('milestone', 'Milestone is required.')

Suggesting wontfix.

[franz.mayer@…]

Replying to osimons:

The ability to modify and validate according to the rules you need is a major reason for why we have a ticket API.

Well, is my requirement really that special? I think there are quite some people, esp. non-technical ones and scrupulous persons, who wants to keep the workflow as specified and no surprising values (such as null for milestone).

Here is a ~10 code lines plugin that will disallow ticket edits where milestone is not set:

I already implemented it in ​TicketNavPlugin, Component SortMilestoneVersion as you see in changeset ​10709 in lines 225-227.

Suggesting wontfix.

Suggesting to either simply implementing it or ship it as tracopt (or as sample?).

[Christian Boos]

Isn't that just a duplicate of #2463?

[anonymous]

Replying to cboos:

Isn't that just a duplicate of #2463?

Well #2463 is kind of a "​eierlegende Wollmilchsau" (all-in-one ticket) in this respect. In our installation, the milestone should be just treated as the fields type, priority, component or severity. In these fields you cannot choose any null value.

[Remy Blank]

Replying to franz.mayer@…:

I think there are quite some people, esp. non-technical ones and scrupulous persons, who wants to keep the workflow as specified and no surprising values (such as null for milestone).

If you make such a claim, you should at least have some numbers to back it up. Otherwise, I can just claim the contrary and we'll have a draw.

I agree with Simon, this is installation-specific and can be done very easily in a plugin.

[anonymous]

Replying to rblank:

Replying to franz.mayer@…:

I think there are quite some people, esp. non-technical ones and scrupulous persons, who wants to keep the workflow as specified and no surprising values (such as null for milestone).

If you make such a claim, you should at least have some numbers to back it up. Otherwise, I can just claim the contrary and we'll have a draw.

Well, I just wanted to make your product a bit better and made also a suggestion how to implement it. If you want a survey, if this feature is feasible, you should make a poll. I am just wondering why for example it is possible to have a null milestone, but it is not possible to have a null component. This would make much more sense to me: a bug-reporter might not know, which component the bug does effect.

I agree with Simon, this is installation-specific and

That's why I implemented it in a way, you could parametrize it in trac.ini.

can be done very easily in a plugin.

Well, if you say "this can be done by a plugin" to everything, Trac is complete, I guess.

[Remy Blank]

Replying to anonymous:

Well, I just wanted to make your product a bit better and made also a suggestion how to implement it.

I may have formulated this a bit strongly, please accept my apologies. And let me explain. We have very frequent feature requests where someone says "Many people want (insert your pet feature here)", where it actually means "I think it's a good idea". I cannot take such a claim seriously without at least some numbers to back it up.

I agree with Simon, this is installation-specific and

That's why I implemented it in a way, you could parametrize it in trac.ini.

can be done very easily in a plugin.

Well, if you say "this can be done by a plugin" to everything, Trac is complete, I guess.

Trac is nowhere near complete, but this specific feature has (from my experience) value for too small a set of users that we should implement it in core. This, combined with the fact that it's easy to do in a plugin, motivates my rejection.

And about configurability through trac.ini, there are already way too many configuration options, and every single one that we add makes Trac more difficult to configure. That's also one motivation not to add every feature to Trac core.

[anonymous]

Replying to rblank: In this way, I understand your motiviation and respect it.

Regarding the "numbers to back it up": You might be right, that I actually should say "I think it's a good idea" ;-) For these numbers, it would be nice to have some poll and I am sure there is already a plugin / ticket.

Well, if anybody else needs the described functionality activate ​Component SortMilestoneVersion in ​TicketNavPlugin. But beware, that this Component does just a little more than just disabling null value milestone (see description at trac-hacks).

[osimons]

Add your vote here: SeaChange/WhatUsersWant