Opened on 04/29/2014 at 02:08:35 PM

Closed on 04/30/2014 at 10:23:20 AM

Last modified on 04/30/2014 at 11:17:03 AM

#403 closed change (fixed)

[trac] remove assigned state but keep assigning feature

Reported by: philll Assignee: philll
Priority: P2 Milestone:
Module: Infrastructure Keywords:
Cc: trev Blocked By:
Blocking: Platform:
Ready: yes Confidential: no
Tester: Verified working: no
Review URL(s):



Trac's "assigned" state is just redundant information to the actual assignee and there is no need to explicitly have a step in the process being named "assigned" apart from knowing that somebody is on it.

What to change

In the adblock plus issue tracker, remove assigned state but keep assigning feature. Ensure all issues currently in the assigned state are being set to some reasonable other state upfront, as it wont be possible afterwards.

Attachments (0)

Change History (8)

comment:1 Changed on 04/29/2014 at 02:08:41 PM by philll

  • Owner set to philll
  • Status changed from new to assigned

comment:2 Changed on 04/29/2014 at 02:33:46 PM by philll

  • Review URL(s) modified (diff)
  • Status changed from assigned to reviewing

comment:3 Changed on 04/30/2014 at 02:51:03 AM by fhd

  • Cc trev added

This is supposed to fix #320, but I'm not fully convinced.

  1. While having an "assigned" state is arguably redundant, it makes it easier to see at a glance that something is being worked on. Assuming this doesn't need to be kept in sync manually.
  2. It seems to me like the underlying problem persists: We cannot move between states arbitrarily. What if you accidentally set something to "reviewing" and want to go back to "new"? Won't work either. I really believe people should always be able to undo things they do.

comment:4 Changed on 04/30/2014 at 07:10:08 AM by philll

  1. It will not fix #320, but make it obsolete, as there will be no assigned state left. As the default queries give you the assignee column either way, I regard that information as obvious enough.
  2. Well, I did not really adress that problem, as I wasn't aware of it so far. Technically, it's easy to allow every state from every other but logically that workarounds the enforcing workflow concept. Although it might be quite arguable, whether it is possible to enforce anything at all, as there are always ways around, if one really wants to. If you think, we should allow that, please file a seperate issue for it.

comment:5 Changed on 04/30/2014 at 07:25:20 AM by trev

Yes, #320 is an issue I mentioned as well in this context - properly unassigning an issue is currently impossible. A more common issue however is that somebody changes to codereview state and forgets assigning - fixing this state currently takes two status changes (back to assigned and the codereview again). Finally, I occasionally set assignee already when creating the issue - and then I have an issue in the "new" state which should really be "assigned".

The way we assign issues the "assigned" state indeed is redundant, in our case anything having an assignee is assigned. And the assignee is displayed by default in every query so I don't see a real issue here either.

comment:6 Changed on 04/30/2014 at 10:23:20 AM by philll

  • Resolution set to fixed
  • Status changed from reviewing to closed

comment:7 Changed on 04/30/2014 at 10:42:22 AM by trev

comment:8 Changed on 04/30/2014 at 11:17:03 AM by fhd

  1. I agree, it's probably obvious enough that something is taken care of if it's assigned to someone. What we had before was redundant and a bit confusing.
  1. We don't need arbitrary state changes per se, all I want is that people can undo things. So why only allow them to move forward in the states? Why not backwards? (e.g. from codereview back to new.)

Add Comment

Modify Ticket

Change Properties
as closed .
The resolution will be deleted. Next status will be 'reopened'.
to The owner will be changed from philll.
Note: See TracTickets for help on using tickets.