More versatile workflow : compatibility with AdvancedTicketWorkflowPlugin

[Frédéric DUARTE <f.duarte@…>]

It would be useful to get email2trac aware of the 'workflow' entry of trac.ini's [ticket] section.

It would help to trigger custom workflow operations that are not handled by Trac's ConfigurableTicketWorkflow.

[Frédéric DUARTE <f.duarte@…>]

Greetings,

We've been using email2trac for a while: great job, Bas !

But we've always been forced to patch it till then. The first reason (out of 2) is that we have a Q&A cycle that implies our customers: we ask them questions, and they answer by email only. Here is the process:

1. We state the required ticket to need_info with the customer's email as owner, then a Trac notification is sent by email to the customer
2. The customer answers by email and then:
   1. the answer is added as comment after a custom quote strip (our 2nd mod, waiting for your strip quotes milestone)
   2. the ticket state changes to 'answered'
   3. the owner gets back to the reporter (or better: to its previous owner)

Now, with the new workflow (great!) feature of release 1.6.0 we are pleased to be about to avoid patching the script ... but the point "the owner gets back to the reporter" can not be handled without a patch ... yet.

"the owner gets back to the reporter" can not handled because it is not an operation proposed by Trac's ConfigurableTicketWorkflow. Fortunately it can be handled by AdvancedTicketWorkflowPlugin. Unfortunately, email2trac is not aware of the 'workflow' entry of the [ticket] section of trac.ini.

It would be great to have this feature extension.

Thanks in advance.

[bas]

when email2trac is started it read the trac environment and starts all plugins. Is the api different for AdvancedTicketWorkflowPlugin? or must i just another api-function that triggers theAdvancedTicketWorkflowPlugin and if not installed uses the default one. I read that you patch the source can the patched by attached?

[Frédéric DUARTE <f.duarte@…>]

Sorry, I'm not aware of Trac API or plug-ins, otherwise I would have provided you with an adequate patch.

Our current patch to customize the workflow for our needs just consists of some hard coded actions that are not really pertinent for this ticket. It just looks like the following lines located in the ticket_update() function around line 830:

        if tkt['status'] in ['need_info']:
                fields['cc'] = ''
                fields['owner'] = tkt['reporter']

Anyway, I think that you could get the list of workflow providers from the trac.ini project and use them in ticket_update() the same way you use ConfigurableTicketWorkflow. It should be the same API otherwise developers would not be able to build any custom workflow handlers ;-).

[bas]

(In [538]) email2trac only used the default workflow. We now use the ticket workflow that is defined in trac.ini, see #226

[bas]

Frédéric,

Can you test this release?

[Frédéric DUARTE]

Hi,

I'm gonna check this, ASAIC. Could take few days, but I'll keep you in touch by the end of the month.

Frédéric.

[bas]

(In [545]) added email2trac_workflow function. So we now honor workflow for new tickets and ticket updates, see #252, #226

[bas]

(In [556]) chamged workflow to TicketModule? implementation as suggested by: Holger Jürgs, see #226

[bas]

(In [557]) delete obsolete workflow code, see #226

[bas]

(In [558]) reporter ticket field can also be changed by a workflow, see #226