Edgewall Software
Modify

Opened 15 years ago

Closed 12 years ago

Last modified 11 years ago

#1440 closed enhancement (fixed)

Remove reached milestones from edit ticket list

Reported by: anonymous Owned by: Matthew Good
Priority: high Milestone: 0.11
Component: ticket system Version: devel
Severity: minor Keywords:
Cc: trac@…, pkou@…, kirean@…, jon.kowal@… Branch:
Release Notes:
API Changes:

Description

This is related to #1078, except on the edit ticket screen. You should not be able to set the milestone to one that has already been reached.

Attachments (6)

Ticket-r1668.py.patch (655 bytes ) - added by Tim Pease <tpease (at) ball (dot) com> 15 years ago.
Patch for Ticket.py (revision 1668)
Ticket-r1668.py.2.patch (652 bytes ) - added by Tim Pease <tpease (at) ball (dot) com> 15 years ago.
Typo in the first patch (damn!). Use this one instead
Remove-Milestones.patch (1.0 KB ) - added by lists@… 13 years ago.
Patch against 0.10.2 which excludes completed milestones from the ticket edit form when the user does not have TICKET_ADMIN permission.
milestone_optgroups.diff (3.1 KB ) - added by Matthew Good 13 years ago.
group open/closed milestones
milestone_optgroups.2.diff (5.3 KB ) - added by Matthew Good 13 years ago.
new patch for trunk
milestone_optgroups.3.diff (5.5 KB ) - added by Christian Boos 12 years ago.
Updated patch for current trunk (r6139)

Download all attachments as: .zip

Change History (50)

comment:1 by Christopher Lenz, 15 years ago

So what if you want to retrospectively assign an already completed ticket to a different milestone (for example, if the original milestone was incorrect).

Maybe a corner case, and maybe should only be available to TICKET_ADMIN folks.

comment:2 by jonathon.jongsma@…, 15 years ago

restricting to TICKET_ADMIN seems like a reasonable solution.

comment:3 by Tim Pease <tpease (at) ball (dot) com>, 15 years ago

Attached is a patch file to Ticket.py (revision 1668) that prevents normal users from selecting a completed milestone, but allows a ticket adminstrator to do so. This is an implementation of the suggestion from jonathon.jongsma@….

This is the same patch for new tickets implemented for #1078, but with the added logic for determining if a user is a ticket administrator.

by Tim Pease <tpease (at) ball (dot) com>, 15 years ago

Attachment: Ticket-r1668.py.patch added

Patch for Ticket.py (revision 1668)

by Tim Pease <tpease (at) ball (dot) com>, 15 years ago

Attachment: Ticket-r1668.py.2.patch added

Typo in the first patch (damn!). Use this one instead

comment:4 by anonymous, 14 years ago

#3085 is marked as duplicate.

comment:5 by anonymous, 14 years ago

Resolution: fixed
Status: newclosed

comment:6 by anonymous, 14 years ago

Resolution: fixed
Status: closedreopened

in reply to:  4 comment:7 by anonymous, 14 years ago

Replying to anonymous:

#3085 is marked as duplicate.

test

comment:8 by Christian Boos, 14 years ago

Before you go further with this, note that this is not a test system.

comment:9 by trac@…, 14 years ago

Cc: trac@… added

I want notifications for this ticket. Hopefully Automattic's SPAM detection behaves now with a comment?

comment:10 by ThurnerRupert <rupert.thurner@…>, 13 years ago

Priority: normalhigh

why an admin should be bothered by closed milestones? especially with systems with many milestones in it it is extremely inpractical that all the milestones show up for a tiny cornercase.

a much better solution would be: if a ticket got added to a wrong milestone, it is no problem to open the milestone again and THEN reassign the ticket to it.

comment:11 by ThurnerRupert <rupert.thurner@…>, 13 years ago

Milestone: 0.10.1

set milestone, as its a very small change helping admin's of longer running projects with many completed milestones.

comment:12 by ThurnerRupert <rupert.thurner@…>, 13 years ago

Resolution: fixed
Status: reopenedclosed

sorry for confusion .. checkt with 0.10.1. it is solved there.

in reply to:  12 comment:13 by Matthew Good, 13 years ago

Milestone: 0.10.10.10.3
Resolution: fixed
Status: closedreopened

Replying to ThurnerRupert <rupert.thurner@gmail.com>:

sorry for confusion .. checkt with 0.10.1. it is solved there.

Actually this has not yet been implemented in Trac. Maybe you've made some local changes to fix this on your end?

comment:14 by Matthew Good, 13 years ago

Owner: changed from Jonas Borgström to Matthew Good
Status: reopenednew

by lists@…, 13 years ago

Attachment: Remove-Milestones.patch added

Patch against 0.10.2 which excludes completed milestones from the ticket edit form when the user does not have TICKET_ADMIN permission.

comment:15 by ThurnerRupert, 13 years ago

you are right - i must be suffering of latent blindness - i applied the patch and removed the exception for admins.

btw most people here work as admins, as they should be able to edit the ticket description - so the above patch would not help a lot.

and, it is (to me in any case) completely counter-intuitive to change a closed milestone (i.e. assigning tickets to it), be it by an admin or not. you could assign an open ticket to a closed milestone, which imo is logically wrong.

comment:16 by Christian Boos, 13 years ago

You're right, I think targeting closed milestone should be possible only for closed tickets, as a way to "fix" a wrongly set milestone.

in reply to:  16 comment:17 by Matthew Good, 13 years ago

Status: newassigned

Replying to cboos:

You're right, I think targeting closed milestone should be possible only for closed tickets, as a way to "fix" a wrongly set milestone.

You may also want to set it to a closed milestone when closing a ticket which was fixed in a past release, but you forgot to close. To avoid complicating this too much I'll stick to the current idea of requiring TICKET_ADMIN permission, but maybe once the WorkFlow stuff is merged it could be handled more robustly.

comment:18 by Matthew Good, 13 years ago

Resolution: fixed
Status: assignedclosed

Fixed in r4296 and r4298. Thanks for the patch.

comment:19 by ThurnerRupert, 13 years ago

i'd be very glad if you could remove the admin exception. it bothers admin's for a very rare edge case. if you forgot to close the ticket for a milestone, where is the problem to open the milestone and then fix the error?

but normally you made your release notes, you plublished maybe some documents, you delivered even software. so opening the milestone if you want to correct this is a minor overhead.

the usual "fault" on our site is, that the first ticket description is wrong/insufficient. this provokes excessive ticket-admins … and then they all get confused by these closed milestones …. and even more errors are made.

may i reopen the ticket?

in reply to:  19 ; comment:20 by Christian Boos, 13 years ago

Replying to ThurnerRupert:

… the usual "fault" on our site is, that the first ticket description is wrong/insufficient. this provokes excessive ticket-admins … and then they all get confused by these closed milestones …. and even more errors are made.

So that's the real problem I think. I'm currently working on #2945. Once this is complete, I think we could reasonably make the description editable by normal TICKET_CHGPROP users.

TICKET_ADMIN should correspond to some "ticket supervisor" person, which should have the right to easily correct what's wrong in a ticket, without much hassle. That could eventually extend to fixing the resolution without having to reopen the ticket, and that certainly covers fixing the milestone information.

For your particular needs, you can easily modify the by removing the admin check, but for the general case, I think my proposal is better.

in reply to:  20 comment:21 by ThurnerRupert <rupert.thurner@…>, 13 years ago

Replying to cboos:

Replying to ThurnerRupert:

… the usual "fault" on our site is, that the first ticket description is wrong/insufficient. this provokes excessive ticket-admins … and then they all get confused by these closed milestones …. and even more errors are made.

So that's the real problem I think. I'm currently working on #2945. Once this is complete, I think we could reasonably make the description editable by normal TICKET_CHGPROP users.

TICKET_ADMIN should correspond to some "ticket supervisor" person, which should have the right to easily correct what's wrong in a ticket, without much hassle. That could eventually extend to fixing the resolution without having to reopen the ticket, and that certainly covers fixing the milestone information.

For your particular needs, you can easily modify the by removing the admin check, but for the general case, I think my proposal is better.

yes. less admins is general a very good idea. we'll check if we can live without admin.

comment:22 by simon, 13 years ago

As a compromise what about about distinguishing between the open and closed milestones in the drop down by crossing out the closed milestones? (similar to closed tickets)

comment:23 by ThurnerRupert, 13 years ago

Milestone: 0.10.30.11
Resolution: fixed
Status: closedreopened
Type: defectenhancement

we have now first experiences. our milestone number is high, and for ticket admins it is unusable as it is. admins tend to do a lot of work in trac, and wrongly assigned milestones are rare. so admins keep scrolling through 40 milestones to find the correct one, 30 of them pointless old ones.

deleting the milestones is also not an option, as the milestone gets removed from the tickets as well and we loose the track record.

also sorting of milestones in the dropdown is improveable, i.e. the "usual milestones" set to tickets are the next ones in time.

so the more we work with it the following improvements seem to be good:

  • only open milestones show up in the dropdown
  • if you have wrongly assigned tickets the following seems most practical:
    • a personal setting "show closed milestones"
    • or let the admin reopen the milestone to correct it
  • sort open milestones by due date in the dropdown

the solution of "changing it in the code just for us" is not really upgrade friendly.

fixing the resolution like proposed by cboos seems appealing. there we have a much higher error rate.

allow me to reopen pls ….

comment:24 by anonymous, 13 years ago

#4811 marked as duplicate.

comment:25 by anonymous, 13 years ago

See also #4910 - providing an ajax autocomplete for milestones would solve this problem.

  1. List only open milestones
  2. If you wish to search for an old milestone, you just have to type its name.

by Matthew Good, 13 years ago

Attachment: milestone_optgroups.diff added

group open/closed milestones

comment:26 by Matthew Good, 13 years ago

I think the biggest problem is that the closed milestones are sorted at the top, so you have to scroll past all of them to get to the open milestones. This patch would help that by splitting them into <optgroup>s with the open milestones at the top.

comment:27 by pkou@…, 13 years ago

Cc: pkou@… added

Another idea is expanding meaning of closed milestones. When milestone is closed, it can mean "completed" and in addition it can mean "archived" (or "expired"). This will require adding new date field to a milestone (when milestone is archived).

This approach resolves the issue with displaying closed milestones in tickets:

  • Display open milestones first (in the roadmap order);
  • Display completed but not archived milestones second (in reverse order of their completeness) - possible for closed tickets only but this is not critical.

When a milestone is marked as completed, users will be able to specify when it becomes archived (by default current date + N days - configurable).

This correlates with #2588 - in addition to the option "Display completed milestones" on the roadmap view there can be an option "Display recently completed milestones", which excludes archived milestones.

Also, this approach works without information loss when a ticket needs to be reassigned to very old milestone: De-archive the milestone by setting some archived date in future and reassign tickets. The milestone will disappear from the tickets view automatically.

Having experience with long-lived projects with many milestones, this idea/use case looks very logical.

Probably, this needs to be discussed in mail list.

comment:28 by Christian Boos, 13 years ago

#4910 was closed as duplicate. It proposed auto-completion for milestone names, as an alternative way to deal with long list of milestones.

comment:29 by anonymous, 13 years ago

#5645 duplicate

comment:30 by Christian Boos, 13 years ago

I'll have a look at reviving mgood's patch.

comment:31 by Matthew Good, 13 years ago

I've updated the patch to work with trunk. If this seems ok to people I'll commit it.

by Matthew Good, 13 years ago

Attachment: milestone_optgroups.2.diff added

new patch for trunk

comment:32 by Christian Boos, 13 years ago

Milestone: 0.11.10.11

Works great.

The idea for the original order between the "per type settings" block was that there could be some named fields which could override the behavior given by their type, but I understand why you made the change (eventually append the current milestone value to the list of options if it's not any longer there).

comment:33 by ThurnerRupert, 13 years ago

could you pls commit it?

comment:34 by paulo@…, 13 years ago

Did someone commit it?

comment:35 by anonymous, 13 years ago

Will this work with 10.4 when it's committed or is it only for 0.11?

comment:36 by kirean@…, 13 years ago

Hi

I just verified that milestone_optgroups.2.diff is not in trunk. I applied it locally and it looks great.

Can we please have this in trunk?

Cheers / Erik

comment:37 by anonymous, 12 years ago

Cc: kirean@… added

comment:38 by kirean@…, 12 years ago

There was a discussion in #trac about this ticket on to close this ticket again. I think that would be a pity since it looks real good from my side..

I'll add it to my local svk branch instead then..

in reply to:  38 comment:39 by Noah Kantrowitz, 12 years ago

Replying to kirean@gmail.com:

There was a discussion in #trac about this ticket on to close this ticket again. I think that would be a pity since it looks real good from my side..

I'll add it to my local svk branch instead then..

I never suggested to close it, just that few admins notice the first part of this implementation is already done (only visible to TICKET_ADMINs) as they don't login as normal users.

by Christian Boos, 12 years ago

Attachment: milestone_optgroups.3.diff added

Updated patch for current trunk (r6139)

comment:40 by Christian Boos, 12 years ago

Matt, I'm not sure you're still monitoring this ticket. I'm going to apply your patch, updated for trunk (attachment:milestone_optgroups.3.diff) unless you're willing to do it yourself.

comment:41 by Christian Boos, 12 years ago

Resolution: fixed
Status: reopenedclosed

Latest patch applied in r6171.

comment:42 by osimons, 12 years ago

#3734 closed as duplicate.

comment:43 by jon.kowal@…, 11 years ago

I got here from duplicate #7779, thanks cboos.

Is there a way to hide completed milestones from users with TICKET_ADMIN? Looking at the source it doesn't seem like it. I face the same problems as stated in comment:23 having 80% of the milestones in the dropdown being completed. In our usage scenario they will never be assigned to any ticket again and there should be a way to hide those even from TICKET_ADMIN users.

comment:44 by jon.kowal@…, 11 years ago

Cc: jon.kowal@… added

Modify Ticket

Change Properties
Set your email in Preferences
Action
as closed The owner will remain Matthew Good.
The resolution will be deleted. Next status will be 'reopened'.
to as closed The owner will be changed from Matthew Good to the specified user.

Add Comment


E-mail address and name can be saved in the Preferences .
 
Note: See TracTickets for help on using tickets.