shortcut to "accept" a ticket when creating it, and enable the "accept" option for other statuses

[cboos]

Long time ago, on the mailing list, I proposed a patch
to immediately set the status of a newly created ticket
to "assigned" if the reporter and the assignee are the
same person.

This saves one step, as the next logical step would be
to "accept" the ticket that the reporter has just created
for himself.

Therefore I propose the patch once again, for discussion:

model.py

@@ -142 +142 @@
                 # Assume that no such component exists
                 pass
 
+        # If the owner creates the ticket, status is directly 'assigned'
+        owner = self.values.get('owner')
+        if owner and owner == self.values.get('reporter'):
+            self['status'] = 'assigned'
+
         # Insert ticket record
         std_fields = [f['name'] for f in self.fields if not f.get('custom')
                       and f['name'] in self.values.keys()]

[cboos]

For now, I still have to accept that ticket manually :)

[cboos]

By the way, I just realized that there's a similar situation
when one reassigns a ticket to oneself:
the ticket would also still have the status new,
when assigned would have been more appropriate.

Here also, it wouldn't make sense to reassign to oneself,
and then not wanting to accept this assignation.

Hence the revised patch:

model.py

@@ -142 +142 @@
                 # Assume that no such component exists
                 pass
 
+        # If the reporter assigns to himself, the status is directly 'assigned'
+        owner = self.values.get('owner')
+        if owner and owner == self.values.get('reporter'):
+            self['status'] = 'assigned'
+
         # Insert ticket record
         std_fields = [f['name'] for f in self.fields if not f.get('custom')
                       and f['name'] in self.values.keys()]
@@ -202 +207 @@
                     # just leave the owner as is.
                     pass
 
+        # If the reporter reassigns to himself, the status is directly 'assigned'
+        owner = self.values.get('owner')
+        if owner and owner == author:
+            self['status'] = 'assigned'
+
         custom_fields = [f['name'] for f in self.fields if f.get('custom')]
         for name in self._old.keys():
             if name in custom_fields:

[cmlenz]

I'm not sure about this. For me, “accepting” a ticket means that I'm starting work on it, I.e. it is in-progress. Just assigning a ticket to myself doesn't necessarily mean that I am planning to start working on it immediately.

Trac is about not imposing process or policies. Different users may have different policies for accepting tickets, and Trac shouldn't make any assumptions here.

[cmlenz]

And about the reassign case you note in the comment, maybe having an accept action for tickets owned by someone else may be a better approach. That way it's at least explicit.

[mgood]

Well, other projects may choose to use it differently, but I believe that the "accept" option should only be used when a ticket is being actively worked on. So, there are certainly times that I would assign a ticket to myself without "accepting" it yet. This is particularly true at work where I have several projects that I'm the only developer on. So, of course I'm the owner of every ticket, but I don't "accept" it until I'm getting started on it.

I'm changing the summary of the ticket since I can see the advantage of having a shortcut (checkbox?) when creating a ticket that would immediately accept it. Also, I think that the "accept" option should be available for all statuses besides "closed". Right now it's only enabled on "new" tickets which means that accepting "reopened" or "accepted" tickets is a two step process which it doesn't need to be.

While we're on this subject, cboos, I think that it would be helpful if you didn't try to accept so many tickets since right now there are over 50 "accepted' tickets in your name, which I don't believe you're actively working on all of them. I think that this leads to confusion for both the developers and users who don't know what's actually being worked on.

[cboos]

Well, according to your or cmlenz's acception of "accepted",
you'd perfectly right.
But I was under the impression that "accepting" a ticket
would merely mean that I "accept" to work on that item.

For me, the current names chosen for the states would rather mean:

• new: not even seen by the developer yet (that's why there's currently so few new tickets owned by me, and for the few who are in that state, it's certainly because I forgot to "accept" them at some point)
• accepted: the issue is acknowledged by the developer
• fixed: done with it
• reopened: oops, not quite

Some other states would be welcomed, but I won't discuss that here.

My point is that it was not at all evident that the "accept" state
would actually mean "I'm working on it".

For tracking current progress at the ticket level, something like
what was suggested in #1084 is far better (cf. flyspray).

But I'm not rigid on that, and if it's the recommended way to go,
I could revert the state of the tickets that I'm not working upon
to the new state.
It's just that this should be documented somewhere...

[direvus@…]

I use the "accepted" status in the same way as cboos. If someone reports a bug to me, I won't accept the ticket until I'm convinced the bug isn't bogus. Likewise an RFE ticket won't be accepted until I'm convinced the enhancement is a good one.

It's not about whether I am working on a ticket, it's about whether I will work on it.

That said, I totally agree with cmlenz's comment that:

Trac is about not imposing process or policies. Different users may have different policies for accepting tickets, and Trac shouldn't make any assumptions here.

Perhaps this should be a user setting, like "Auto-accept when assigning tickets to yourself? <checkbox>"

[rob]

This should be enabled as a user setting. I also want tickets I assign myself to be auto-accepted

[peter.becker@…]

If you want the scheme cmlenz proposes, I'd like to see a separate "assigned" state between "new" and "accepted". Alternatively there could be an additional boolean attribute "accepted", in which case "new" should probably be named "unassigned" and the semantics of new would be covered by the pair "unassigned"/"not accepted".

At the moment I'd consider the UI as inconsistent and we got confused since we had some tickets missing from queries where we expected them.

A particular inconsistency for me is that reassigning an accepted ticket to the empty string changes the status to "new". That is inconsistent with reassigning a new ticket to someone, where the status does not change.

[opensource@…]

How about adding an additional status like "in progress"?

So there would be:

• new
• accepted
• in progress
• closed
• reopen

[srussell@…]

I agree with some of the posts above: I prefer to use "accepted" as a tag that I'm actively working on a ticket.

To address some of the other comments, though, wouldn't a special "assigned" state be redundant? If there's a name in "Assigned to:" then it's assigned. If it's the default (somebody?) then it's not assigned.

[kelk@…]

I have recently installed trac, and I am very happy with it.

However it is NOT clear to the users of the system, that they need to "accept" a ticket.
So most people newer do this. This may lead to queries with incomplete results.

In our case it would be nice, either to not have the accepted state at all - or to always auto-accept - also when assigning to others.

In my world you have the defect until you reassign it. The scheme with having bugs owned but not assigned leads to tickets in "no mans land".
The idea of using "assigned" as "in progress" is to me mixing defect-management too much with project-management. Defects are either fixed or not - in progress is irrelevant when you e.g. need to decide whether to release or not...

[athomas]

Regardless of how a particular user interprets the states, I think it's quite confusing that using the reassign action makes the state new, whereas accepting the ticket makes it assigned.

WorkFlow will allow this to be customised of course, but making the current behaviour more logical would be good IMHO. This would require assign action and an accepted state.

[cboos]

+1, see also my last comment on #1689, which stated essentialy the same thing.

[fumanchu@…]

For what it's worth, I implemented the same patch as cboos, and was ready to open a new ticket for y'all before I found this one.

+1 on making this configurable. I would've guessed it should be a conf-file entry, though, not a per-user setting. If it is made a per-user setting, I want to be able to default it to True site-wide.

[cboos]

For the record, #2315 and #2732 are also duplicates of this ticket.

[cboos]

In most BTS, the new state means not yet processed.

From the discussion above and others, it seems like a majority of the TracTeam wanted to have the accepted state (accepted as defined in comment:13) to be used as an indicator of "Someone is actively/currently working on this".

We probably need something in between, meaning "this ticket has been noticed and the team decided what to do about it". Currently, this is done by assigning a milestone, which is not that satisfying (there might be valid ticket for which no milestone are adequate). A better solution would probably an acknowledged state.

And this brings me back to the very topic of this ticket: my original request for enhancement was Ticket should be immediately 'assigned' after creation when assigned to the reporter. This could be rephrased: Ticket should be immediately 'acknowledged' after creation when assigned to the reporter, provided we have that acknowledged state.

Opposed to the acknowledged state, there should also be a needinfo state, i.e. the ticket has been seen but can't be processed further until some more details are given (#2944).

So this would give the following first steps of the workflow:

1. create new ticket -> (new) state
2. (new) : seen and "triaged", the verb could be validate -> (acknowledged) state
3. (new) : seen but can't decide, the verb could be question -> (feedback) state

(feedback or needinfo, same thing)

So this ticket is about doing 1. and 2. in one step at ticket creation time, when the reporter assigns the ticket to himself. Now I hope that this sounds unquestionable ;)

[sid]

Oh, I can't wait for workflow. Then everyone can do it their own way.

[cboos]

#4749 is also discussing the default workflow.

[anonymous]

I cannot Accept a Reopened ticket. (10.3) Is this by design ? That is, i fix a ticket, now it is closed, tester/manager reopens, now it's reopened, I should now be able to Accept this ticket, but this option is not available.

Maybe design is that tester reopens, then manager must reassign ( even though it is assigned to me already ), then it gets New status (what? that's no good, as you mention several times here, that reopened != new ).

[ecarter]

WorkFlow is in trunk now. Note that the default workflow was left as it was, warts and all. However, the framework is in place so that a reasonable default workflow can be chosen, along with several examples for the common use cases.

[osimons]

Didn't the discussions & decisions on the new 'fixed default workflow' committed as [5658] essentially resolve this issue for 0.11?

[osimons]

#6584 closed as a duplicate - after initial recommendation of using plugin and custom workflow.

[ecarter]

The part of this enhancement that remains is being able to take custom workflow actions upon ticket creation. Customizable workflow does not provide a hook into ticket creation, nor am I planning to add one for the 0.11 series. Deferring to 0.12.

[b5]

It would be cool if you would built the proposed patch in and have a config variable to enable it. It should not cost others much performance. But I am used since more than two years to create tickets for myself and then immediately accept them. Because for us "accept" came to mean "saw it, will do it, no questions now, not declined". I think it may mean this in many rougher environments actually, where avoiding blame games is part of how trac helps.

Thank you!