Remove reached milestones from edit ticket list

[anonymous]

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.

[cmlenz]

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.

[jonathon.jongsma@…]

restricting to TICKET_ADMIN seems like a reasonable solution.

[Tim Pease <tpease (at) ball (dot) com>]

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.

[Tim Pease <tpease (at) ball (dot) com>]

Patch for Ticket.py (revision 1668)

[Tim Pease <tpease (at) ball (dot) com>]

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

[anonymous]

#3085 is marked as duplicate.

[anonymous]

Replying to anonymous:

#3085 is marked as duplicate.

test

[cboos]

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

[trac@…]

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

[ThurnerRupert <rupert.thurner@…>]

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.

[ThurnerRupert <rupert.thurner@…>]

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

[ThurnerRupert <rupert.thurner@…>]

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

[mgood]

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?

[lists@…]

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

[ThurnerRupert]

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.

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

[mgood]

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.

[mgood]

Fixed in r4296 and r4298. Thanks for the patch.

[ThurnerRupert]

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?

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

[ThurnerRupert <rupert.thurner@…>]

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.

[simon]

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)

[ThurnerRupert]

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

[anonymous]

#4811 marked as duplicate.

[anonymous]

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.

[mgood]

group open/closed milestones

[mgood]

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.

[pkou@…]

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.

[cboos]

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

[anonymous]

#5645 duplicate

[cboos]

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

[mgood]

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

[mgood]

new patch for trunk

[cboos]

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).

[ThurnerRupert]

could you pls commit it?

[paulo@…]

Did someone commit it?

[anonymous]

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

[kirean@…]

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

[kirean@…]

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

[nkantrowitz]

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.

[cboos]

Updated patch for current trunk (r6139)

[cboos]

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.

[cboos]

Latest patch applied in r6171.

[osimons]

#3734 closed as duplicate.

[jon.kowal@…]

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.