Ticket system reuse

[andrew.sharpe1@…]

I'd like to be able to control the ticket interface at all times. I am currently unable to do this without reproducing the code in trac.ticket.web_ui._do_save()

The reason for this is the redirect at the end of _do_save(). If that redirect was placed elsewhere, then the _do_save() method would be available for use by others and they would still retain control of the clients location.

[mgood]

It sounds like you just want to extend the built-in ticket modules, but you're using a different URL for your custom module. Instead just extend your class from the built-in one then disable the built-in one in trac.ini or through the WebAdmin plugins tab. Then your plugin will be responsible for handling a request for /ticket/123 instead of Trac's default ticket module.

If you need some help please ask on the development MailingList with more specifics about what you're trying to do, but I don't think it will require modifying the Trac source. If after discussion on the MailingList it appears a change is required we can reopen this ticket.

[andrew.sharpe1@…]

Hi Jonas, you're right, the changes aren't required, but they do make your code resusable. Currently, we can't reuse the ticket saving code in the ticket module and I don't think it would be wise to reimplement it - introduce other bugs etc. I'll create a patch and let you have a look.

Andrew

[mgood]

Replying to andrew.sharpe1@jcu.edu.au:

Hi Jonas, you're right, the changes aren't required, but they do make your code resusable. Currently, we can't reuse the ticket saving code in the ticket module and I don't think it would be wise to reimplement it - introduce other bugs etc. I'll create a patch and let you have a look.

Well, I'm not Jonas, I'm Matt :)

My point was not that you should reimplement it, but that you're probably not reusing the ticket module enough. If you post a brief description of what you're trying to accomplish on the development MailingList I'll try to provide an example of inheriting from the built-in ticket module to handle that. Simply patching _do_save may lead to problems down the road for your plugin. The underscore prefix implies that it's intended as part of the class's internal API, not for public use, so reusing it directly may break your plugin if it changes in the future. So before patching it I'd like to make sure there's not a better way for your plugin to handle this.

[andrew.sharpe1@…]

Replying to mgood:

Replying to andrew.sharpe1@jcu.edu.au:

Hi Jonas, you're right, the changes aren't required, but they do make your code resusable. Currently, we can't reuse the ticket saving code in the ticket module and I don't think it would be wise to reimplement it - introduce other bugs etc. I'll create a patch and let you have a look.

Well, I'm not Jonas, I'm Matt :) My point was not that you should reimplement it, but that you're probably not reusing the ticket module enough. If you post a brief description of what you're trying to accomplish on the development MailingList I'll try to provide an example of inheriting from the built-in ticket module to handle that. Simply patching _do_save may lead to problems down the road for your plugin. The underscore prefix implies that it's intended as part of the class's internal API, not for public use, so reusing it directly may break your plugin if it changes in the future. So before patching it I'd like to make sure there's not a better way for your plugin to handle this.

Sorry about that Matt, my bad assumption.

Cheers for the tip, that's a much more elegant solution. I've done what you've suggested and it works a treat, now I just have to do that for both the TicketModule? and the NewTicketModule?.

Thanks again,

Andrew