The filter "iteration" is missing in custom query links of the page "Iterations"

[ja11sop]

Ok, thanks. Acknowledging this and moving to the current milestone.

[ja11sop]

Resolving this is not so straightforward but being able to make a general query like this would certainly simplify several parts of the plugin.

[dfraser]

I think the best way to solve this would be to separate out the tickets column of iteration into a separate table, so you have iteration_ticket which links iterations and tickets... This would also make it easier to enable adding tickets to an iteration from the ticket etc...

[dfraser]

Patch to the plugin to adjust the database

[dfraser]

The two patches above together work successfully for me...except that the query forgets the Iteration if you alter it, so I'll look at that next.

[dfraser]

Patch to trac to put iteration's tickets in separate table and allow querying through that table (remembers query)

[dfraser]

That most recent version (forgot to replace) now remembers the Iteration in the query. It's not ideal since you can select "Iteration is not 3" and that doesn't work, but at least it makes altering the other parts of the query usable.

[dfraser]

And a semi-final version that handles "is", "is not", and multiple query items for Iterations.

[dfraser]

Patch to trac to put iteration's tickets in separate table and allow querying through that table

[dfraser]

Patch to trac to put iteration's tickets in separate table and allow querying through that table (fixes admin screen)

[ja11sop]

just adding a reference here to #45 which is also related to this

[ja11sop]

I think if we are going to make a schema change (I believe we should and the patch looks good from a a cursory glance) then we should also add a description field to the iteration. The idea would be to use the 'summary' field of the iteration as the 'title' and then allow a 'description' to be used for more detailed information, including custom queries for example. I believe there is another story relating to this. I'll grab the reference later.

[dfraser]

Replying to ja11sop:

I think if we are going to make a schema change (I believe we should and the patch looks good from a a cursory glance) then we should also add a description field to the iteration. The idea would be to use the 'summary' field of the iteration as the 'title' and then allow a 'description' to be used for more detailed information, including custom queries for example. I believe there is another story relating to this. I'll grab the reference later.

Agreed - it's #115

[ja11sop]

I think the only thing missing from this patch is the changes required in the plugin to upgrade the database. This is also needed for #115. Essentially we need to do three things:

1. Create a new table called iteration_ticket 2. Populate the table with all current values from the tickets column in the iteration table 3. Update the iteration table so that it no longer has the tickets column

[dfraser]

Replying to ja11sop:

I think the only thing missing from this patch is the changes required in the plugin to upgrade the database. This is also needed for #115. Essentially we need to do three things: 1. Create a new table called iteration_ticket 2. Populate the table with all current values from the tickets column in the iteration table 3. Update the iteration table so that it no longer has the tickets column

Ah, that's actually there, but in a different file, even more confused by the way I've forgotten to tick "this replaces the previous patch".

So basically:

• agiletrac-70-iteration-tickets.patch is a patch to the agiletracplugin that upgrades the database (this needs the new description column from #115 folded in)
• agiletrac-70-iteration-tickets-trac.3.patch is the latest version of the patch to the agiletrac branch of trac that implements the rest of this...

[ja11sop]

Yes - after taking the time to read it again I see you are quite right. I assume there was a preference to naming the columns iteration_id and ticket_id over iteration and 'ticket respectively? Actually I think I might prefer that way. On my local copy I had originally gone with the second option but think I prefer the one in this patch. I think with an updated db2.py` file based on the combination of the one in the patch here and the one associated with #115 these patches should be applied to the DEV branch. These changes are much needed :-)

[ja11sop]

We'll also need to update setup.py to bump the version number to 0.2.2.dev - see attached patch.

[ja11sop]

Forgot to say the reason for bumping the version is so we can do an easy_install -U upgrade to force the db upgrade.

[ja11sop]

Ok - I added a unified patch for all that we've discussed so far in this ticket. One final change I think we should probably make is to rename the summary column of the iteration table to name (or title) so that it more accurately reflects the intended use, but this is not essential. Milestone, Version etc all use name and description whereas ticket use summary and description so leaving it might be ok too. Thoughts are welcome.

[ja11sop]

Please note I've been testing the unified patch and updated it slightly so it actually works.

[ja11sop]

I've made (hopefully) the last update to this patch for now. I think it is ready for committing. The main change I made was to add an 'Iterations' column to the work table view that adds an iteration link for each iteration that the ticket appears in.

[ja11sop]

Unified patch for plugin and patch to add the iteration_ticket table and add the description field to iterations, also add iteration-ticket mapping to roadmap and tickets (updated 14th Oct 2009)

[ja11sop]

Ok, patch updated once more. This is just a preliminary exposure of the iteration_ticket table info on the roadmap and on tickets. We will want to review all this later on but this current patch provides a simple and useful exposure of the information now available.

[ja11sop]

Committed r310 to the DEV branch

[ja11sop]

r313 is the revision that actually has all files and changes required

[dfraser]

Last leftover patch to prevent string for iteration.tickets

[dfraser]

Great, thanks for getting the description in there and making it all work. It's really useful having the Iterations column in the work table view as well.

I've attached a leftover patch to prevent iteration.tickets becoming a string (everywhere else it's a list) - will probably commit this shortly as it's pretty clear.

The only other difference I noticed comparing my patch was that you didn't leave (iteration, ticket) as the primary key of the iteration_ticket table - that will allow multiple copies of the same ticket on the same iteration. Also making the primary key causes it to index, which we should probably do if it's not going to be the primary key.

[dfraser]

Replying to dfraser:

I've attached a leftover patch to prevent iteration.tickets becoming a string (everywhere else it's a list) - will probably commit this shortly as it's pretty clear.

Committed as r324

[ja11sop]

Ok - I am not sure I follow what you are saying about the primary key for the iteration_ticket table. My intention was that the primary key would be (iteration, ticket), that is,

key=('iteration_id', 'ticket_id')

I want to prevent the same ticket appearing more than once in the same iteration, but allow a ticket to appear in more than one iteration. I have no problem modifying this if it makes sense to do so.

On a separate, but important note, I also noticed that the DB upgrade in Postgresl seems to reset the iteration sequence back to 1 which means you can no longer add iterations. I think we need explicit protection against this as part of the upgrade though I am not sure how. Have you seen this? Any suggestions?