#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: | |||
Internal 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)
Change History (50)
comment:1 by , 20 years ago
comment:3 by , 20 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 , 20 years ago
Attachment: | Ticket-r1668.py.2.patch added |
---|
Typo in the first patch (damn!). Use this one instead
comment:5 by , 18 years ago
Resolution: | → fixed |
---|---|
Status: | new → closed |
comment:6 by , 18 years ago
Resolution: | fixed |
---|---|
Status: | closed → reopened |
comment:9 by , 18 years ago
Cc: | added |
---|
I want notifications for this ticket. Hopefully Automattic's SPAM detection behaves now with a comment?
comment:10 by , 18 years ago
Priority: | normal → high |
---|
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 , 18 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.
follow-up: 13 comment:12 by , 18 years ago
Resolution: | → fixed |
---|---|
Status: | reopened → closed |
sorry for confusion .. checkt with 0.10.1. it is solved there.
comment:13 by , 18 years ago
Milestone: | 0.10.1 → 0.10.3 |
---|---|
Resolution: | fixed |
Status: | closed → reopened |
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 , 18 years ago
Owner: | changed from | to
---|---|
Status: | reopened → new |
by , 18 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 , 18 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.
follow-up: 17 comment:16 by , 18 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.
comment:17 by , 18 years ago
Status: | new → assigned |
---|
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 , 18 years ago
Resolution: | → fixed |
---|---|
Status: | assigned → closed |
follow-up: 20 comment:19 by , 18 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?
follow-up: 21 comment:20 by , 18 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.
comment:21 by , 18 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 , 18 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 , 18 years ago
Milestone: | 0.10.3 → 0.11 |
---|---|
Resolution: | fixed |
Status: | closed → reopened |
Type: | defect → enhancement |
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:25 by , 18 years ago
See also #4910 - providing an ajax autocomplete for milestones would solve this problem.
- List only open milestones
- If you wish to search for an old milestone, you just have to type its name.
comment:26 by , 18 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 , 18 years ago
Cc: | 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 , 18 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:31 by , 17 years ago
I've updated the patch to work with trunk. If this seems ok to people I'll commit it.
comment:32 by , 17 years ago
Milestone: | 0.11.1 → 0.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:36 by , 17 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 , 17 years ago
Cc: | added |
---|
follow-up: 39 comment:38 by , 17 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..
comment:39 by , 17 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 , 17 years ago
Attachment: | milestone_optgroups.3.diff added |
---|
Updated patch for current trunk (r6139)
comment:40 by , 17 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 , 17 years ago
Resolution: | → fixed |
---|---|
Status: | reopened → closed |
Latest patch applied in r6171.
comment:43 by , 16 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 , 16 years ago
Cc: | added |
---|
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.