Edgewall Software
Modify

Opened 2 years ago

Closed 2 years ago

Last modified 2 years ago

#10553 closed enhancement (fixed)

[PATCH] Additional milestone operation for sample-plugins

Reported by: framay <franz.mayer@…> Owned by: framay <franz.mayer@…>
Priority: normal Milestone: 1.0
Component: contrib Version:
Severity: normal Keywords: patch workflow
Cc:
Release Notes:

Add MilestoneOperation sample plugin, a workflow operation which assign a ticket to a milestone for some specific resolution values

API Changes:

Description

We have following workflow in my company:

If a ticket is rejected (which means not fixed / implemented) it will be moved to a milestone 'rejected'. Thus we have clean milestones with only implemented features / solved bug fixes.

It would be nice, if this could be parametrized using Trac workflow. I have implemented this in attached file MilestoneOperation.py. Maybe the attached file could be committed in sample-plugins, when there are no further comments regarding better / nicer implementation.

Plugin description:


Sets milestone for specific status.

Example

[ticket-workflow]
resolve.operations = set_resolution,set_milestone
resolve.milestone = invalid,wontfix,duplicate,worksforme->rejected

When setting status to duplicate the milestone will automaitcally change to rejected.

Note: if user has changed milestone manually, this workflow operation has no effect!

Configuration

Don't forget to add MilestoneOperation to the workflow option in [ticket] section. If there is no workflow option, the line will look like this:

[ticket]
workflow = ConfigurableTicketWorkflow,MilestoneOperation

Attachments (2)

MilestoneOperation.py (4.1 KB) - added by framay <franz.mayer@…> 2 years ago.
Plugin file for set_milestone operation
MilestoneOperation.2.py (4.6 KB) - added by framay <franz.mayer@…> 2 years ago.
improved version of component MilestoneOperation

Download all attachments as: .zip

Change History (7)

Changed 2 years ago by framay <franz.mayer@…>

Plugin file for set_milestone operation

comment:1 follow-up: Changed 2 years ago by cboos

  • Milestone set to next-dev-1.1.x

Looks good, just found a typo: resoltions.

Also, you should add the

revision = "$Rev$"
url = "$URL$"

keys, and also author and author_email with your contact informations (same kind of policy as in contrib/ I'd say).

Changed 2 years ago by framay <franz.mayer@…>

improved version of component MilestoneOperation

comment:2 in reply to: ↑ 1 Changed 2 years ago by framay <franz.mayer@…>

Replying to cboos:

Looks good, just found a typo: resoltions.

Replaced resoltions with resolutions in method __get_resolution_milestone_dict.

Also, you should add the

revision = "$Rev$"
url = "$URL$"

keys, and also author and author_email with your contact informations (same kind of policy as in contrib/ I'd say).

Added licence info with author and author email as well as revision and url. Is this OK as I did it?

comment:3 Changed 2 years ago by cboos

  • Milestone changed from next-dev-1.1.x to 1.0
  • Resolution set to fixed
  • Status changed from new to closed

I added MilestoneOperation.py to trunk/sample-plugins/workflow in r11227.

While testing it I did the following changes:

  • style: don't use dict.has_key(k) but k in dict or even dict.get(k) when appropriate; test against None with is/is not None
  • in render_ticket_action_control, status was used when this was actually about resolutions
  • the check for a Milestone existence was wrong… here's another victim of #4130 ;-)

A more subtle fix: if a milestone was set, and the ticket got reopened, then closing it again with a resolution which was not mapped would clear the milestone.

There's still a problem, not due to the plugin but rather to the well-known issue that we have trouble differentiating changes made by the user and changes made by the workflow: after an explicit "Preview" action, the new milestone set by the workflow becomes the "user defined" milestone, and as such it sticks. At least we have the "(revert)" action if needed, so it's not critical.

comment:4 Changed 2 years ago by cboos

  • Owner set to framay <franz.mayer@…>

comment:5 Changed 2 years ago by cboos

  • Release Notes modified (diff)

Add Comment

Modify Ticket

Change Properties
<Author field>
Action
as closed The owner will remain framay <franz.mayer@…>.
The resolution will be deleted. Next status will be 'reopened'.
to The owner will be changed from framay <franz.mayer@…> to the specified user.
Author


E-mail address and user name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.