#226 closed enhancement (duplicate)
Ticket Dependencies
Reported by: | Owned by: | Jonas Borgström | |
---|---|---|---|
Priority: | lowest | Milestone: | |
Component: | general | Version: | 0.6 |
Severity: | normal | Keywords: | |
Cc: | trac@… david.balch@… | Branch: | |
Release Notes: | |||
API Changes: | |||
Internal Changes: |
Description
I don't know if this is outside the idea of the Trac being simple, but it would be nice to be able to have tickets that depend on other tickets being completed, so that you can get an idea of what needs to be done.
Attachments (1)
Change History (7)
comment:1 by , 20 years ago
Milestone: | → 2.0 |
---|---|
Priority: | normal → lowest |
comment:2 by , 20 years ago
Cc: | added |
---|
I would like to get the ball rolling on this one.
I'm not sure why daniel thinks this would have to be a bug change. I think it can implementing this can be pretty staight forward.
I'll just post the basic idea of what I'm working on, feedback would be much apreciated.
DB Schema: Add a table to record dependencies:
CREATE TABLE dependencies ( blocks int, dependson int, UNIQUE(blocks,dependson) );
Ticket object: Add two methods .get_blocks_list() .get_dependson_list() that return a list of Tickets "blocked by this Ticket" and a list of Tickets "this Ticket depends on" respectively.
Change the .save_changes method to check/ act on these list on status change.
UI changes: Add the required fields to display and change these dependencies.
comment:3 by , 20 years ago
I just added a patch implementnig basic Ticket dependency functionality.
I had to rework the patch quite a bit as Ticket.py has seen some major chanegs since 0.7.1
I'm still a bit puzzled about how/ why some of Ticket.py works the way it does. So I expect some things could be handled cleaner than I did in this patch. I guess the main thing is getting something that works out there and get some feedback on the progress this far.
Things that should work:
All the basic stuff should work.
- Adding/removing/editing Tickets "the current Ticket blocks" to existing bugs.
- Adding/removing/editing Tickets "this Ticket Depends on" to existing bugs.
- Reverse blocking/depending i.e. If Ticket #1 one blocks Ticket #2. Ticket #2 obviously 'depends on' Ticket #1
- Adding 'blocks'/'depends on' to new tickets.
N.B. The 'Blocks' and 'Depends On' fields only display direct dependencies, it doesn't walk up or down the dependency graph to find all dependencies.
Stuff that might work:
- Automatic update of the database. I haven't tested, but I think it should work. (If not use the CREATE TABLE from the previous comment if you want to test).
Things that don't work/ isn't done
- Input validation
- Sanity checks (a Ticket can depend on non-existing Tickets, Can both depend on and block the same Ticket, etc..)
- Act when dependencies are violated. (I.e. prevent closing when blocknig Tickets are open, reopen when depending ticket is reopened, etc).
- Display of fancy dependency graphs
- probably a lot more.
Some of the things from this list probably should be done before this can be useful. But for now this should give a basic idea about how this could work.
comment:4 by , 20 years ago
Cc: | added; removed |
---|
comment:5 by , 20 years ago
Resolution: | → duplicate |
---|---|
Status: | new → closed |
This is a duplicate of #31. Take any further comments there to avoid fragmentation.
comment:6 by , 19 years ago
Milestone: | 2.0 |
---|
This is a big change… Maybe for post-1.0.