[Patch] Big change to the child table functionality

[anonymous]

I've made a major change to the way that childticketsplugin handles the table of children. It has a few drawbacks but the benefits are very significant. I think it needs someone else to look over it and come up with some ways to tidy it up. changes are as follows:

• Removed the child table completely - The code was building a table in full when trac has the wiki engine to do this
• Added a custom field called childreport
• Added a ticket_created and ticket_changed handler to update the childreport of the parent ticket with a TicketQuery macro

There are a few caveats.

• If you change the macros, the parent does not get updated until you update a child.
• The ticket_custom table is updated every time a ticket is changed, regardless of whether it needs to be
• You cannot edit the childreport macro, it will always be overwritten when a child is modified

Benefits are pretty simple

• Allows you to use wiki macros to define the table, i.e. grouping and data on rows
• The wikitext field can also be used in custom queries

There are a few things I don't like. The code to handle the table_headers definition is a bit obscure. I've used a closure as it saves a bit of extra coding when i'm getting configuration directives but its not particularly readable. I've also not properly handled migrating from the child table to my version. Maybe we could add a config directive to tell it to use a field instead of rendering a table.

Screenshot of the ticket screen is also attached along with a diff.

Pete

[anonymous]

Custom query with child tickets subtables

[plt]

Hi, Does anyone have any thoughts on this patch? I'm keen to get some feedback, especially about how to keep it compatible with the original or even if its useful to anyone other than me. Pete

[Mark Ryan]

Hi Pete

Sorry - I've been 'off line' for a while... I'll try and get this patch installed on my system here in the next couple of days and give you some feedback.

My first thought is 'Keep It Simple ...' and that makes me a little wary of the extra custom field, but I do like the reports it allows one to produce.

As for the table that gets rendered,if there's a better way then it must be a good thing (I wrote the original plugin for trac v0.10 and back then I had to include a patch to allow the table to be written correctly).

I'll give feedback asap - although I'd also like to hear from other people as my company is (unfortunately!) no longer using Trac I'm probably not the best person to provide feedback on what functionality people 'really' want to see.....

[Mark Ryan]

Pete - can you send me the details of the new custom field that needs to be defined. I have installed the patch but I see no tickets on the 'Childreport' field.....

I am guessing I need to set up the custom field a little differently.

Cheers Mark

[anonymous]

Hi Mark, I've been a bit lax on the documentation here... I'm not entirely happy with the patch but it does do a job quite nicely. I really don't like the way i'm adding the child report in though. To get it to work, you need to create a new field called childreport, set it to a wiki textarea. It then shows as a row in the reports. I can only populate the field when a ticket is created or saved though which i'm not happy with. The table headers are read from this line

'childtickets', 'parent.%s.childreport' % ptickettype

so you need to create a lline with parent.bugfix.childreport = [TicketQuery()] A default ticket=$TICKET entry gets added and then this gets hard coded into the value that goes into the field. If you don't put this in, it should fallback to the legacy fields, but you do need to modify and save the ticket to get it to work properly.

I've been looking at an alternative way to do this. It really needs a virtual field that can be defined. That in turn needs a $TICKET field that gets filled with the ticket id from the row. It looks like it needs to be added to the ticket.py file in the main part of trac but it doens't have any extension points so i've not been able to implement anything.

Let me know how you get on Pete

[Mark Ryan]

Hi Pete

I've taken a look at the changes you made and I'm not sure I want to go down the route of maintaining more 'custom_ticket' fields and the associated problems of them (potentially) getting out of sync. I am also a bit nervous about the 'automatic updating' of the custom field values - if someone changes a child ticket and that then updates one or more parent tickets, then any modifications being made (manually) to those parent tickets would be blocked (I think!) (btw. I am also generally distrusting of anything that does any 'automatic updates' - even my own code!)

For me, another disadvantage of having the 'childreport' as a custom field is that I cannot get it to span the whole width of the ticket - depending on how much info you want displayed, I think that might be a point for some people.

The BIG advantage it has is the ability to see the child tickets in queries and reports (I've been trying to think of a way of doing this for a while now!). I think a list of child tickets (even in compact form) would be a great feature to have in this plugin....

Since I've had trac 0.12 installed, I've also been wanting to change the child ticket table to use the 'foldable' classes that the 'attachments' and 'Comments' sections use (I've committed the changes as 2.0.0-BETA ​here). The child tickets are now completely apart from the ticket header section and can be collapsed and 'ignored' more easily.

I'd be grateful if you could take a look at the '2.2.0-BETA' version I've committed and see if you think it improves the overall look and usability of the plugin.

In the meantime, I'm going to try and see if I can use any of your changes to get some childticket information in the query/reports.

Speak soon Cheers Mark

[Mark Ryan]

No Activity