Edgewall Software
Modify

Opened 9 years ago

Last modified 2 months ago

#2045 assigned enhancement

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

Reported by: cboos Owned by: rjollos
Priority: normal Milestone: 1.1.3
Component: ticket system Version: devel
Severity: minor Keywords: workflow
Cc: andrew.c.martin@…, rjollos, olemis+trac@…, ethan.jucovy@…
Release Notes:
API Changes:

Description

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

     
    142142                # Assume that no such component exists 
    143143                pass 
    144144 
     145        # If the owner creates the ticket, status is directly 'assigned' 
     146        owner = self.values.get('owner') 
     147        if owner and owner == self.values.get('reporter'): 
     148            self['status'] = 'assigned' 
     149 
    145150        # Insert ticket record 
    146151        std_fields = [f['name'] for f in self.fields if not f.get('custom') 
    147152                      and f['name'] in self.values.keys()] 

Attachments (3)

workflow_with_create_action.png (15.7 KB) - added by rjollos 4 months ago.
workflow_with_default_owner.png (27.8 KB) - added by rjollos 4 months ago.
workflow_no_default_owner.png (27.2 KB) - added by rjollos 4 months ago.

Download all attachments as: .zip

Change History (40)

comment:1 Changed 9 years ago by cboos

  • Status changed from new to assigned

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

comment:2 Changed 9 years ago by 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

     
    142142                # Assume that no such component exists 
    143143                pass 
    144144 
     145        # If the reporter assigns to himself, the status is directly 'assigned' 
     146        owner = self.values.get('owner') 
     147        if owner and owner == self.values.get('reporter'): 
     148            self['status'] = 'assigned' 
     149 
    145150        # Insert ticket record 
    146151        std_fields = [f['name'] for f in self.fields if not f.get('custom') 
    147152                      and f['name'] in self.values.keys()] 
     
    202207                    # just leave the owner as is. 
    203208                    pass 
    204209 
     210        # If the reporter reassigns to himself, the status is directly 'assigned' 
     211        owner = self.values.get('owner') 
     212        if owner and owner == author: 
     213            self['status'] = 'assigned' 
     214 
    205215        custom_fields = [f['name'] for f in self.fields if f.get('custom')] 
    206216        for name in self._old.keys(): 
    207217            if name in custom_fields: 

comment:3 Changed 9 years ago by 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.

comment:4 Changed 9 years ago by 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.

comment:5 Changed 9 years ago by mgood

  • Summary changed from Ticket should be immediately 'assigned' after creation when assigned to the reporter to shortcut to "accept" a ticket when creating it, and enable the "accept" option for other statuses

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.

comment:6 Changed 9 years ago by 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…

comment:7 Changed 9 years ago by 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>"

comment:8 Changed 8 years ago by rob

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

comment:9 Changed 8 years ago by 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.

comment:10 Changed 8 years ago by opensource@…

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

So there would be:

  • new
  • accepted
  • in progress
  • closed
  • reopen

comment:11 Changed 8 years ago by 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.

comment:12 Changed 8 years ago by 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…

comment:13 Changed 8 years ago by athomas

  • Milestone set to 0.11

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.

comment:14 Changed 8 years ago by cboos

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

comment:15 Changed 8 years ago by 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.

comment:16 Changed 8 years ago by cboos

  • Keywords workflow added
  • Priority changed from low to normal
  • Severity changed from trivial to minor

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

comment:17 Changed 7 years ago by cboos

  • Status changed from assigned to new

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 ;)

comment:18 Changed 7 years ago by sid

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

comment:19 Changed 7 years ago by cboos

#4749 is also discussing the default workflow.

comment:20 Changed 7 years ago by 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 ).

comment:21 Changed 7 years ago by 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.

comment:22 Changed 6 years ago by osimons

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

comment:23 Changed 6 years ago by osimons

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

comment:24 Changed 6 years ago by ecarter

  • Milestone changed from 0.11.1 to 0.12

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.

comment:25 Changed 4 years ago by 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!

comment:26 Changed 4 years ago by Andrew C Martin <andrew.c.martin@…>

  • Cc andrew.c.martin@… added

comment:27 Changed 4 months ago by rjollos

  • Cc rjollos added

For the sake of consistency, I think it would be nice to have tickets in the assigned state whenever they have an owner. The issue has been raised numerous times in various tickets and on the mailing list, that many users find it confusing that a ticket can be in the new state and yet have an owner. This is confusing because we often say the ticket is assigned to the owner (see #8484).

I'm inclined to tackle this issue in a different ticket, and need to understand the constraint described in TracWorkflow that 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. I'd just want to make sure that having a ticket start in the assigned state doesn't break any of the internals of Trac. Most likely it could cause issues for plugins that are mining the ticket_change table for state transitions (e.g. it looks like the th:TimeVisualizerPlugin is doing this), so the change should probably be made on a major release.

Last edited 4 months ago by rjollos (previous) (diff)

comment:28 Changed 4 months ago by rjollos

It occurred to me, why don't we just add the Workflow actions to the New Ticket form? With that change, we can remove the Set Owner field, and the owner would only be set through the workflow. If the owner can only be set through the workflow, then it will behave more like the resolution field, and we remove the inconsistency of having tickets "assigned to" an owner and not in the assigned state. The ticket creator could then put the ticket directly in any state for which the Workflow supports a transition from new (or "pre-new"), and for which the creator has the appropriate permissions.

I've implemented the initial changes and will post them tomorrow. This was a pretty quick proof-of-concept test, so I'm sure there are issues to resolve still. Two questions that I'll explore next are:

  • Should we have a "pre-new" state in the workflow? That would determine what state transitions are allowed when creating the ticket. I'm leaning towards implementing this because I think we can make the actions and action hints more clear (see screen captures below for current behavior).
  • If a ticket is created in a state other than new, should we have an entry in the changelog? I've seen users complain on trac-hacks about plugins that create tickets with a state other than new, as it causes challenges, e.g. when trying to count the number of tickets created in a time period.

Workflow with [ticket] default_owner = < default >

Workflow with [ticket] default_owner =

[ticket-workflow]
accept = new,assigned,accepted,reopened -> accepted
accept.operations = set_owner_to_self
accept.permissions = TICKET_MODIFY
leave = * -> *
leave.default = 1
leave.operations = leave_status
reopen = closed -> reopened
reopen.operations = del_resolution
reopen.permissions = TICKET_CREATE
resolve = new,assigned,accepted,reopened -> closed
resolve.operations = set_resolution
resolve.permissions = TICKET_MODIFY
assign = new -> assigned
assign.permissions = TICKET_MODIFY
assign.operations = set_owner
reassign = assigned,accepted,reopened -> assigned
reassign.permissions = TICKET_MODIFY
reassign.operations = set_owner
unassign = assigned -> new
unassign.permissions = TICKET_MODIFY
unassign.operations = del_owner

If we add a pre-create state to the workflow, I was thinking it might look something like this:

create = none -> new
create.permissions = TICKET_CREATE
create.operations = set_default_owner
accept = none,new,assigned,accepted,reopened -> accepted
accept.operations = set_owner_to_self
accept.permissions = TICKET_MODIFY
leave = * -> *
leave.default = 1
leave.operations = leave_status
reopen = closed -> reopened
reopen.operations = del_resolution
reopen.permissions = TICKET_CREATE
resolve = new,assigned,accepted,reopened -> closed
resolve.operations = set_resolution
resolve.permissions = TICKET_MODIFY
assign = none, new -> assigned
assign.permissions = TICKET_MODIFY
assign.operations = set_owner
reassign = assigned,accepted,reopened -> assigned
reassign.permissions = TICKET_MODIFY
reassign.operations = set_owner
unassign = assigned -> new
unassign.permissions = TICKET_MODIFY
unassign.operations = del_owner
Enable JavaScript to display the workflow graph.

Side note: Maybe delete could be an action as well, which terminates in the none state?

The dialog might look something like this for the default workflow:

Having only create as new seems a little off because every action creates the ticket. Maybe we should have create and assign to, create and accept?

Last edited 4 months ago by rjollos (previous) (diff)

Changed 4 months ago by rjollos

Changed 4 months ago by rjollos

Changed 4 months ago by rjollos

comment:29 follow-up: Changed 4 months ago by rblank

This sounds like a good idea. It would remove the hardcoding of "new" as the initial state of every ticket (it would simply be a default), a complaint that we've had a few times in the past. I'm not sure about the deletion part, but that's largely independent and could be addressed later.

comment:30 Changed 4 months ago by ethan.jucovy@…

This approach wouldn't fully prevent tickets with state="new" from having an owner set, right? [ticket] default_owner, and component owners, and ITicketChangeListener plugins, would still be able to cause a ticket to get an owner set without its state changing from "new". If true, I think this is a good thing.

I was also going to respond to comment:27 pointing out that I do often need "new" tickets with owners — in a lot of my trac sites, "new" means "this ticket has not yet been acknowledged", but it might still be a particular person's responsibility to acknowledge the ticket. (I sometimes remove the leave action from "new" tickets, so that any ticket edit at all — even just a comment or a description edit — constitutes acknowledgement, and moves the ticket into the "assigned" state.) I would still be able to configure this behavior by altering the pre-create workflow action's operations, right?

Side note: I'd love to see what your implementation looks like, and how (if at all) it alters the ITicketActionController interface; for my th:WorkflowNotificationPlugin I had to use some nasty hacks to trigger emails on ticket creation, since the ITicketChangeListener methods provide less context than the ITicketActionController methods. I'd be very happy if I could get rid of the ITicketChangeListener code in that plugin and only use action controller methods.

comment:31 Changed 4 months ago by Olemis Lang <olemis+trac@…>

  • Cc olemis+trac@… added

regarding comment:28 , fwiw +1

comment:32 Changed 4 months ago by gary.martin@…

From what I can tell, with the suggested changes from rjollos, it should still be possible to model the current workflow by only defining the transition from "none" to "new". I think I would expect any required upgrades to conserve the existing behaviour of projects even if there is a desire to provide a new default workflow for new installations.

As a nice side-effect, dropping the hardcoding of the "new" state would give the possibility of providing the "new" state with a more meaningful name to suit the intended use of the state if desired.

On the assumption that this can be implemented, there is obviously going to be a chance that "none" is a defined state in existing installations. I was idly wondering whether it would be possible avoid the potential for conflicts by defining a special form for the definition rather than having a string defining this "none" state. Not sure if just the following would make enough sense:

create = -> new

comment:33 Changed 4 months ago by rjollos

Initial changes to add the workflow controls to the new ticket page can be found in log:rjollos.git:t2045. The next step is to add the creation workflow action and associated state, and then determine behaviours for options such as [ticket] default_action.

comment:34 Changed 4 months ago by ethan.jucovy@…

  • Cc ethan.jucovy@… added

comment:35 in reply to: ↑ 29 Changed 4 months ago by rjollos

Replying to rblank:

… I'm not sure about the deletion part, but that's largely independent and could be addressed later.

Yeah, I don't intend to approach that in this ticket. Initially I was just thinking that it offers a nice symmetry to have create and delete in the workflow. Having delete as an action in the workflow for a ticket doesn't seem to offer any immediate advantages (and could actually be less convenient that the delete button), but it could be useful on the batch modify form. If we wanted to add the ability to delete multiple tickets in a single operation it might fit nicely into the workflow actions of the batch modify form.

One use case I can think of is, users tag tickets as spam and an administrator is responsible for deleting them - batch delete would be much more convenient.

There's a fork of the th:TicketMoverPlugin that integrates ticket moves into the workflow, which is also an interesting use-case for the workflow that may involve create and delete operations. I haven't looked into the details of the implementation.

Last edited 4 months ago by rjollos (previous) (diff)

comment:36 Changed 3 months ago by rjollos

  • Milestone changed from next-major-releases to 1.1.3
  • Owner changed from cboos to rjollos
  • Status changed from new to assigned

comment:37 Changed 2 months ago by rjollos

#9799 was closed as a duplicate, requesting a way to translate the new and closed statuses.

Add Comment

Modify Ticket

Change Properties
<Author field>
Action
as assigned The owner will remain rjollos.
The ticket will be disowned. Next status will be 'new'.
as The resolution will be set. Next status will be 'closed'.
to The owner will be changed from rjollos 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.