Edgewall Software
Modify

Opened 3 years ago

Closed 3 years ago

Last modified 3 years ago

#10384 closed enhancement (wontfix)

Disable setting null-milestone

Reported by: franz.mayer@… Owned by:
Priority: normal Milestone:
Component: ticket system Version: 0.12.2
Severity: normal Keywords:
Cc: osimons
Release Notes:
API Changes:

Description

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.

Attachments (0)

Change History (10)

comment:1 follow-up: Changed 3 years ago by 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.

comment:2 in reply to: ↑ 1 ; follow-up: Changed 3 years ago by 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?).

comment:3 Changed 3 years ago by osimons

  • Cc osimons added

comment:4 follow-up: Changed 3 years ago by cboos

Isn't that just a duplicate of #2463?

comment:5 in reply to: ↑ 4 Changed 3 years ago by 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.

comment:6 in reply to: ↑ 2 ; follow-up: Changed 3 years ago by rblank

  • Milestone 0.13 deleted
  • Resolution set to wontfix
  • Status changed from new to closed

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.

comment:7 in reply to: ↑ 6 ; follow-up: Changed 3 years ago by 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.

comment:8 in reply to: ↑ 7 ; follow-up: Changed 3 years ago by rblank

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.

comment:9 in reply to: ↑ 8 Changed 3 years ago by 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).

comment:10 Changed 3 years ago by osimons

Add your vote here: SeaChange/WhatUsersWant

Add Comment

Modify Ticket

Change Properties
<Author field>
Action
as closed The ticket will remain with no owner.
The resolution will be deleted. Next status will be 'reopened'.
to The owner will be changed from (none) to the specified user.
Author


E-mail address and user name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.