Default values of ticket workflow fields should be configured in the [ticket-workflow] section

[Ryan J Ollos]

The fields resolution and status in the list of Ticket.protected_fields (tags/trac-1.0.2/trac/ticket/model.py@:51-52#L49​) are only modified by the workflow. #2045 moves Trac one step closer to adding owner to Ticket.protected_fields and only allowing the workflow to change the owner field (see comment:60:ticket:2045).

Having default_resolution and default_owner as attributes of a ticket workflow action and configured through the [ticket-workflow] section rather than the [ticket] section has a few advantages:

• It should be clear that these fields are controlled by the ticket workflow.
• Unique default values can be provided for each action in the workflow.

I've also found the attribute names set_owner and set_resolution to be a bit confusing. We might consider renaming these to resolutions / owners or allowed_resolutions / allowed_owners.

For completeness, we could also consider adding restrict_owner as a workflow attribute, replacing or overriding [ticket] restrict_owner. This was mentioned in comment:1:ticket:11976.

[Ryan J Ollos]

TODO After this ticket is implemented we can redefine the documented constraints on the ticket workflow (wiki:1.1/TracWorkflow#BasicTicketWorkflowCustomization):

There are a couple of hard-coded constraints to the workflow. In particular, tickets are created with status new, and tickets are expected to have a closed state. Further, the default reports/queries treat any state other than closed as an open state.

[Ryan J Ollos]

Replying to rjollos:

On second thought I think the constraint of having a ticket in the new state doesn't depend on this ticket, though #11858 is somewhat important to completely eliminating that constraint. However, after this ticket is implemented we can discuss in the documentation how the population of the owner field can be driven by the workflow.

Documentation updated in 1.1/TracWorkflow@7.

[Ryan J Ollos]

To support all possible use cases related to #7979, we might want to have a special <user> value that refers to the currently logged-in user. That would support two cases not handled by set_owner_to_self:

• Specifying a restricted set of users via the set_owner attribute and including the currently logged-in user in that set.
• Specifying the currently logged-in user as the default_owner.

[Ryan J Ollos]

#10913 closed as a duplicate, requesting the ability to set a default value for the set_owner workflow operation.

[Ryan J Ollos]

Narrowing focus for 1.1.4.

[Ryan J Ollos]

Milestone renamed

[Ryan J Ollos]

Narrowing focus for milestone:1.2. Please move ticket to milestone:1.2 if you intend to fix it.

[Ryan J Ollos]

Milestone renamed

[Ryan J Ollos]

Milestone renamed