ticket	summary	type	release	owner	status	created	modified	_description	_reporter
9195	Form fields not editable but visible after certain workflow stage	enhancement	0.11		new	2011-09-21T23:00:50+02:00	2020-10-29T05:07:09+01:00	I would like to both built-in or custom fields not editable but visible after certain stage in the workflow.	canh.tran@…
3402	set_field_to_owner?	enhancement	0.11		new	2008-07-17T09:06:20+02:00	2020-10-29T05:07:09+01:00	"How about a set_field_to_owner to complement set_owner_to_field?

{{{
fix = inprogress -> needs_review
fix.operations = set_field_to_owner
fix.set_field_to_owner = fixedby
.
.
.
fail = in_testing -> failed
fail.operations = set_owner_to_field
fail.set_owner_to_field = fixedby
}}}
"	J Evan S
3537	Defaults in owner drop downs	enhancement	0.10		new	2008-08-12T05:13:24+02:00	2020-10-29T05:07:09+01:00	It would be nice to have the ability to set defaults in the owner dropdown. For example, when a ticket is resolved, rather than just being able to set_owner_to_reporter it would be great to just leave it as set_owner but have the ability to say that the default user selected in the drop down would be the reporter.	nlovinsky@…
6988	Using set_owner_to_previous in case reporter and owner are the same	enhancement	0.11		new	2010-04-15T08:12:26+02:00	2020-10-29T05:07:09+01:00	"I'm using

set_owner_to_reporter
when resolving a ticket, so the reporter has to confirm the resolved ticket.
On confirmation the ticket is closed where I'm using 
set_owner_to_previous
in order to close the ticket and to have as owner the one who has resolved the ticket (statistics).
In case that somebody reported a ticket to himself the
set_owner_to_previous 
will set the owner empty, as it seems that there were no previous owner as all the time reporter and resolving owner were the same.

Can you please change the set_owner_to_previous to keep the current owner in case there is no previous owner???"	anonymous
9502	set_field_to_value	enhancement	0.12	Ryan J Ollos	accepted	2011-10-28T09:43:52+02:00	2020-10-29T05:07:29+01:00	"The workflow in our organization knows a 'review_by_architect' state and a 'submit_to_testing'.
With both actions leading to these states, our developers set the next owner manually for each ticket.
Because both architect and testing each have a single, fixed account, we would greatly benefit from this action

{{{
set_field_to_value (TicketWorkflowOpFieldValue) 

    Sets a ticket field to a value specified in trac.ini

    <someaction>.operations = set_field_to_value
    <someaction>.set_field_to_value.field = mycustomfield
    <someaction>.set_field_to_value.value = peter
}}}
"	anonymous
3151	Two requests: Assign to specific user, Send email	enhancement	0.11		new	2008-06-10T02:45:06+02:00	2020-10-29T05:07:09+01:00	"Looking for two features:

 1. The ability to assign to a particular user without having them on the ticket.  Something like TicketWorkflowOpOwnerField but where you can specify the username instead of the Field.
 1. The ability to send off a custom email notification.  In our case it's an email to mailing list that a ticket has reached a certain state and we don't want to force use of that mailing list on the CC (makes for very verbose chatter).  This is what I'm trying to achieve by using TicketWorkflowOpRunExternal in #3150."	gmr@…
7520	[Patch] Ability to have a default status on triage operations	enhancement	0.11		new	2010-08-19T16:23:53+02:00	2020-10-29T05:07:09+01:00	"Added ability to have a default status on triage operations.

The following example will set the status to reopen by default but to bug type tickets it will set development.

Example:
{{{
reopen = closed -> *
reopen.operations = del_resolution,triage,del_owner
reopen.permissions = TICKET_CREATE
reopen.triage_field = type
reopen.triage_split = *->reopened,bug->development
}}}

SVN Diff:
{{{
Index: controller.py
===================================================================
--- controller.py       (revision 8373)
+++ controller.py       (working copy)
@@ -354,13 +354,16 @@
                                 action + '.triage_field').strip()
         transitions = self.config.get('ticket-workflow',
                                       action + '.triage_split').strip()
+        default_status = 'new'
         for transition in [x.strip() for x in transitions.split(',')]:
             value, status = [y.strip() for y in transition.split('->')]
             if value == ticket[field].strip():
                 break
+            else:
+                if value == '*':
+                    default_status = status
         else:
-            self.env.log.error(""Bad configuration for 'triage' operation in action '%s'"" % action)
-            status = 'new'
+            status = default_status
         return status
}}}"	norberto.bezi@…
8548	[Patch] request ability to use multiple fields in a triage	enhancement	0.11		new	2011-03-01T00:51:48+01:00	2020-10-29T05:07:09+01:00	it would be extremely nice to be able to use an arbitrary number of fields in a triage. If this is already possible, then it would be extremely nice if it were documented.	anonymous
9127	Triage not working on 0.12.x	defect	0.12		new	2011-08-27T17:40:02+02:00	2020-10-29T05:07:09+01:00	"I have reproduced the same flow as the one provided in the example for the triage.
So when you accept the ticket into the workflow, the status doesn't get updated accordingly. You see that there have been an update in the comment but this is empty.
I tried on 2 different install with 0.12.x, without success (no problem on a quick try on 0.11)

Set_status_to_previous and set_owner_to_previous are working.

I haven't tried the others.

Yannick"	yannick.derechapt@…
9554	triage problem with action leave BEFORE triaged	defect	0.12		new	2011-11-23T08:54:05+01:00	2020-10-29T05:07:09+01:00	"Trac 0.12.2
Ubuntu 10.04
AdvancedTicketWorkflowPlugin 0.11dev-r9962

My workflow is configured to triage the ticket according to ticket type from {{{new}}} to {{{working_(task)}}} or {{{working_(cr)}}}.
Having a ticket in state {{{new}}}, doing some changes (comments, milestones, doesn't matter what) and using action {{{leave}}} (configured as in default workflow) causes an error in {{{controller.py}}} class {{{TicketWorkflowOpTriage}}} method {{{_new_status}}}, because variables ""{{{transistions}}}"" and ""{{{field}}}"" are empty. So the line ""{{{value, status = [y.strip() for y in transition.split('->')]}}}"" failes because there is nothing to unpack.

{{{
   def _new_status(self, ticket, action):
        """"""Determines the new status""""""
        field = self.config.get('ticket-workflow',
                                action + '.triage_field').strip()
        transitions = self.config.get('ticket-workflow',
                                      action + '.triage_split').strip()
        if not field and not transitions:
            return ticket['status']
        else:
            for transition in [x.strip() for x in transitions.split(',')]:
                value, status = [y.strip() for y in transition.split('->')]
                if value == ticket[field].strip():
                    break
            else:
                self.env.log.error(""Bad configuration for 'triage' operation in action '%s'"" % action)
                status = 'new'
            return status
}}}

After adding the ""{{{if not field and not transitions:}}}"" everthing works fine!"	anonymous
14104	set_owner not working, when combined with triage since Trac 1.0.18, 1.2.6 and 1.4.1	defect	1.4	Ryan J Ollos	accepted	2022-01-06T21:42:22+01:00	2022-04-07T01:42:40+02:00	"When using latest stable Trac 1.4.3 with AdvancedTicketWorkflowPlugin, some combined workflow operations (i.e. `set_owner,triage` will not work). 

The desired action is missing the `set_owner` content:\\
[[Image(missing_action.png)]]\\
This is the expected action:\\
[[Image(expected_action.png)]]

Setup to reproduce is basically the follwing:
* run Trac 1.4.3 with source:/advancedticketworkflowplugin@18458
* add multiple users with `TICKET_MODIFY` permissions (or higher)
* use the following configuration options in `trac.ini`:
{{{
[ticket]
restrict_owner = enabled
workflow = ConfigurableTicketWorkflow,TicketWorkflowOpTriage
}}}
* add the following action to the default Trac workflow in `trac.ini`:
{{{
[ticket-workflow]
split = new -> *
split.operations = set_owner,triage
split.label = queue and reassign
split.triage_field = type
split.triage_split = defect -> new_defect, enhancement -> new_enhancement, task -> new_task
}}}

I'm running Trac 1.0.5 with AdvancedTicketWorkflowPlugin (and other plugins) and I want to update several installations to any current stable Trac release. 
But after checking the code, it seems, that all current Trac releases (since 1.0.18/19, 1.2.6, 1.4.1) are running into this issue, as two specific Trac improvements ([https://trac.edgewall.org/changeset/16954 Trac r16954] and [https://trac.edgewall.org/changeset/17141 Trac r17141]) have been integrated in all stable Trac branches.
By debugging the issue, I can describe the problem the following way:
1. Both workflow controllers (`ConfigurableTicketWorkflow` and `TicketWorkflowOpTriage`) are used as expectd.
1. `set_owner` action will deactivate action display, as next_status is `'*'` (due to `triage` usage) in [https://trac.edgewall.org/browser/branches/1.2-stable/trac/ticket/default_workflow.py?annotate=blame,rev=17307#L395 render_ticket_action_control()].
1. Diplaying label, widget, hint will be skipped in [https://trac.edgewall.org/browser/branches/1.4-stable/trac/ticket/web_ui.py?annotate=blame,rev=17499#L459 _get_action_controls()].
1. `triage` action works as expected.

I'm not a Python programmer (but I can read the code) and don't know much on the Trac/Plugins architecture. From my point of view, the problem could be solved in Trac itself, or maybe in this plugin, when the target status placeholder `*` could be replaced by something else, when using the triage operation. 

If anybody could give a hint on a possible solution or workaround, would be great. If it is helpful to better create the ticket in the Trac system (because maybe the problem can not e solved in the plugin), I can provide this, too.
"	mw@…