Christian Boos wrote: > Alec Thomas wrote: >> On Thu, Jan 11, 2007 at 12:08:11PM +1100, Dave Cole wrote: >> >>> We used to use the old workflow branch here for a project we are working >>> on as a joint venture with another company. The old workflow was not >>> able to do all that we wanted, so we have since implemented our desired >>> >> I'm not sure why this would be. Everything you describe below, except >> for the additional detail in the milestone view, is doable with a plugin >> for the old Workflow branch. Are you talking about limitations of the >> default configurability? The plugin system? > > Well, another reason is probably that the old WorkFlow branch is simply > ... old, and they want to use recent 0.10 or 0.11dev (as it seems to be > the case). Is that branch still in the "don't touch" state? :-) > > If not, what could be quite easily done I think and would satisfy 80% of > the needs, would be to implement the trac.ini configurable part only. > Doing this by abstracting from the current code and > http://www.object-craft.com.au/~djc/trac0.11dev.patch shouldn't be that > hard. > > The rest could still be done later, of course. I'm all in favor of > "incremental" steps happening "for real" instead of big changes forever > postponed, as you haven't been the only one hit by this problem ;) > > Dave: the modifications you've done to the roadmap.py code could > probably be done as a plugin, implementing the ITicketGroupStatsProvider > interface.
OK - I can see how to do that now. I cannot see a clean way to configure the ticket actions via a plugin. Should the TicketSystem.get_ticket_actions() be implemented via an ExtensionPoint delegate? More generally, should the ticket permissions/actions and status be implemented in something like an ITicketWorkflowProvider with the current functionality enclosed in something like DefaultTicketWorkflowProvider? That would remove all of our hacks to ticket/api.py and ticket/web_ui.py (except for the ability to edit owner at will). Then you are left with templates/ticket_view.html. Presumably there is something sensible that can be done to remove that Python code from the template and provide a method on the Ticket that invokes a new TicketSystem method to get_ticket_buttons() or something. That would in turn delegate to the ITicketWorkflowProvider. After implementing the above I suppose the rest is a minor fiddle to roadmap.css and macros.html. Is there a sneaky way to avoid those changes? - Dave - Dave --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Trac Development" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/trac-dev?hl=en -~----------~----~----~----~------~----~------~--~---
