New tickets should have a default owner

[louis@…]

I think that when a ticket is raised it should be assigned to someone by default, as external bug reporters are not likely to know the names of developers on the project (and hence may leave new tickets unassigned). For example, I would not know who this ticket should be assigned to, and as such I haven't assigned it to anyone when raising it.

If a team is using email notification as their primary process for discovering new tickets, an unassigned ticket will not be discovered.

I think this could be solved in a number of ways, one is to notify one user delegated as the project manager.

Another solution may be related to #870.

Yet another might just be to document this and recommend users set up reports to deal with this problem.

[louis@…]

Sorry, I missed a crucial part of my explanation. I meant that new tickets should have a default owner if that ticket is raised against a component that does not have an owner.

Then if the ticket was assigned to some catch-all project manager type of person, that would probably solve this issue.

[bitserf@…]

Patch to implement default fallback owner if no component owner or user-provided owner

[bitserf@…]

I've attached the patch we use here for this functionality. It uses the value of the "default_owner" setting in the [ticket] section of trac.ini if its supplied, if one of the following applies:

• The user did not provide an owner and there is no owner for the component
• The user did not provide an owner and there was no component selected

[bitserf@…]

fixed patch

[sid < >]

One way this can be solved is using TracNotification. In particular, see:

smtp_always_cc: List of email addresses to always send notifications to. Typically used to post ticket changes to a dedicated mailing list.

I use this successfully to get emails about all new tickets on my project. It also sends emails about any ticket changes, so can be a little noisy, but it will definitely keep you in the loop about any ticket changes, especially to unassigned ones.

[Christian Boos]

There are solutions for this problem: either use smtp_always_cc as sid suggested, or simply assign an owner to each component through the WebAdmin interface, it's really easy… (if [ticket] restrict_owner is set to true, it's not even possible to create a new component without an owner, in WebAdmin).

But currently, when a new ticket is set to a component with no owner, the owner is set to some value, whereas it should be at least cleared.

In order fix this, we might implement a default_owner setting (with a default to the empty string), for consistency with the other fields which also have a default_... setting.

[Eli Carter]

Replying to cboos:

(if [ticket] restrict_owner is set to true, it's not even possible to create a new component without an owner, in WebAdmin).

Which I took to be a bug, #6912, now fixed.

But currently, when a new ticket is set to a component with no owner, the owner is set to some value, whereas it should be at least cleared.

In order fix this, we might implement a default_owner setting (with a default to the empty string), for consistency with the other fields which also have a default_... setting.

Agreed.

[Eli Carter]

[ticket] default_owner is already implemented. (As is default_cc for that matter.) All builtin fields except id and status support a [ticket] default_<fieldname> setting. The problem is that this default will override the ticket component owner due to #5497.

[anonymous]

I think the solution would be to implement default_component_owner setting which will be used in the following way:

• When you create a new component - that owner should be pre-selected in the UI
• If new ticket is submitted with no owner set and ticket component either not selected or that component doesn't have an owner assigned - then owner will be taken from that default_component_owner setting

[Christian Boos]

Replying to ecarter:

[ticket] default_owner is already implemented. (As is default_cc for that matter.) All builtin fields except id and status support a [ticket] default_<fieldname> setting. The problem is that this default will override the ticket component owner due to #5497.

I'm not sure what's the current status with this.

I think it should work like this:

• the owner for a newly created is the default owner for the selected component
• if there's none, then it will be the default_owner
• if there's none, there will be no default owner

[anonymous]

Is it possible to set default owner to creator? If the creator doesn't assign to anybody, then the ticket will be under his/her name.

[guy@…]

This is the how the trunk behaves:

1. if a default_owner is set, then the login of the default_owner will appear under the owner field in the new ticket form.
2. if the default_owner is empty when submitting the form, and the component has an owner, then the owner will be set as the component owner.
3. if the default_owner is empty in submission, and the component does not have an owner, then the ticket will not get an owner.

I don't think this the expected behavior. These are the changes I think that should be implemented: the owner field by default should be blank. next to the owner field, there should be a button that say something like 'assign to component owner' — that will just put inside the field the owner of the chosen component, if exists, and if not, the default_owner. I think this is necessary because it is not intuitive for the end user (who is not familiar with the project, nor with trac) that submitting an empty owner means the default owner. if the user still chose to submit the ticket with an empty owner, it will be assigned to the component owner if exists, and if not, to the project owner.

[Eli Carter]

Replying to guy@…:

I think this is necessary because it is not intuitive for the end user (who is not familiar with the project, nor with trac) that submitting an empty owner means the default owner.

I agree that having an empty owner mean the default isn't very intuitive and invites users to pick an owner at random just to fill out the bug report completely. On the other hand, I don't like adding a button for filling out the field. What about having the value start as either "<auto>" or "<default>", and apply the component owner/default owner logic if the user submits the owner as that sentinel value?

[Guy Rozendorn <guy@…>]

Replying to ecarter:

What about having the value start as either "<auto>" or "<default>", and apply the component owner/default owner logic if the user submits the owner as that sentinel value?

sounds good. everyone agrees?

[Remy Blank]

"< default >" sounds good to me.

[anonymous]

Replying to rblank:

"< default >" sounds good to me.

I can't see how "default" is anywhere different from "NULL".

I don't know if that's the case of a different workflow but, in my world, the person rising the ticket has neither the knowledge nor the interest to set a ticket owner: all the issuer is interested in is the ticket being resolved (or eventually what's the current state of a ticket he is interested in), not who is going to do it.

In fact, I'd say that should be quite common: ticket creators are "clients" of the system while stablishing who, when, how, is going to fix the ticket is a matter for the project manager/component owner (if it happens that the ticket issuer is a member of the developing team is just a case where the same person hold two roles).

Of course, flexibility is always a good thing but if I were given the choice of either the ticket creator must always to set a ticket owner (eventually with the help of the tool that would set a default owner) or never being able to set the ticket owner at all (and then ticket ownership set by someone taking the ticket for himself or any kind of administrator setting ownership to a member of a team after the fact) I would surely choose the latter.

[Eli Carter]

proposed patch

[Eli Carter]

The proposed patch makes the default_owner be "< default >", and if that is the value of the owner, then the component owner is used. I don't think we need to have a 'default component owner'; just assign owners for all components. Having a non-blank default should be clearer for users so they don't just try to assign a ticket at random.

Bother; it breaks the regression tests, so it needs some more work.

[Eli Carter]

fixed patch

[Remy Blank]

All tests pass here on trunk, and the patch works as advertised. Great work!

[Eli Carter]

Committed to trunk [10645].

[Ryan J Ollos]

Replying to ecarter:

[ticket] default_owner is already implemented. (As is default_cc for that matter.) All builtin fields except id and status support a [ticket] default_<fieldname> setting.

#11856 proposes to move the default_ value for a field under control of the ticket workflow (some of the protected_fields: tags/trac-1.0.2/trac/ticket/model.py@:51-52#L49​) to the [ticket-workflow] section.

[Ryan J Ollos]

Replying to louis@…:

If a team is using email notification as their primary process for discovering new tickets, an unassigned ticket will not be discovered.

I think this could be solved in a number of ways, one is to notify one user delegated as the project manager.

Another solution may be related to #870.

Yet another might just be to document this and recommend users set up reports to deal with this problem.

With the proposed changes in #2045 and #11856 there will many additional possibilities. You can have a ticket create workflow action that defaults the owner to a project manager, or even strictly assigns a ticket to the project manager without giving the user a choice. You could have different ticket create workflow actions for different users, perhaps assigning tickets created by external users to a user responsible for ticket triage, and giving internal users the choice of who to assign ticket to. A permission can be used to determine which create action is available to each user. When a ticket is moved to the next state in the workflow, which is often the assigned state, the owner can default to the component owner. It feels like we have a large range of flexibility to cover different scenarios with the proposed changes.

[Ryan J Ollos]

Replying to anonymous:

Is it possible to set default owner to creator? If the creator doesn't assign to anybody, then the ticket will be under his/her name.

After #2045 is implemented this can be done using the set_owner_to_self operation in the ticket create workflow action.

[Ryan J Ollos]

Changes from this ticket have been documented in TracUpgrade#Behaviorofticketdefault_ownerchanged.

There's been some additional discussion about the value < default >, see comment:51:ticket:2045 for a summary. #11857 proposes to add <default> and <component_owner> as allowed values for the field.