Tus comentarios
I think that both things could co-exist. For example I could open a ticket that is relative to a bug, or a task, or a "change request", etc.... and in the meantime, a bug could be referred to an UI issue, or a DB exception, etc.....
As I told you in another discussion the reason is that "filters" are not "persistent".
Reasonly, Closed bugs will not be open or read anymore, but now still remain in bugs list. Everytime that I open project, I see all tickets, including closed one, and I should filter that. Then I open detail of a ticket, come back to list and again... closed tickets are visible, so I should filters again...... If filters would be persistent across sessions, could be enough but is not so.
In addition, this need is risen today not because I move closed tickets to a specific project, but because at the moment is not possible to open sub-tasks. I have many tickets related to one topic or funcitonality, so I created some projects that I consider "sub-projects" to move relative tickets, in order to better classify them.
Reasonly, Closed bugs will not be open or read anymore, but now still remain in bugs list. Everytime that I open project, I see all tickets, including closed one, and I should filter that. Then I open detail of a ticket, come back to list and again... closed tickets are visible, so I should filters again...... If filters would be persistent across sessions, could be enough but is not so.
In addition, this need is risen today not because I move closed tickets to a specific project, but because at the moment is not possible to open sub-tasks. I have many tickets related to one topic or funcitonality, so I created some projects that I consider "sub-projects" to move relative tickets, in order to better classify them.
I can add the flagging "Remember me" on login, could be very useful if session could span acroos hours or better... days. Not only few minutes.....
I already posted my status in last comment........
I add my opinion about custom states. For Example, here status for BUGs:
* Recorded - ticket is created by a user but still assigned to him and not visible to all other project members. He can continue to edit it in order to track errors and adding details, before publish it.
* New/Open - ticket created by a user and published in order to make it visible to all project members. In this status it is still not confirmed by a reviewer (in big projects one person often verifies details and existence of a bug before assign it to a developer)
* Confirmed - ticket confirmed by a reviewer and assigned to a developer
* Taken into Account - ticket read and taken into account by developer that will solve it as soon as possible
* Started/In Progress - ticket is in "work in progress" status
* Pending - ticket is commented by developer, assigned to reporter in order to receive more clarification on it; in this status responsibility of ticket is owned by Reporter
* Completed/Resolved - ticket is developed by a developer in its local machine for example but not delivered on an environment testable by reporter or by a tester. Is useful for a devoloper to know that he already solved but still not visible to customer.
* Delivered - solution of bug is delivered on a TEST environment in order to be tested by reporter, and ticket is assigned to reporter
* Closed - ticket is considered solved by reporter, closed and unassigned; this status should also hide ticket from main tickets list
We could add also other status for specific issues, for example:
* Clone - ticket is a clone of another one. Reviewer could set this status and automatically link it to the original one.
In order to manage not only bugs but also "Change requests", we could add the following status (many others are shared with previous ones):
* Quoted - CR asked in tickets is quoted by a developer (such as "1 day of work") and assigned back to customer in order to allow it to accept estimation and give ok to developing.
* Accepted - customer accepted estimation and assigned again to developer that will change ticket to "Taken into account" status.
* Recorded - ticket is created by a user but still assigned to him and not visible to all other project members. He can continue to edit it in order to track errors and adding details, before publish it.
* New/Open - ticket created by a user and published in order to make it visible to all project members. In this status it is still not confirmed by a reviewer (in big projects one person often verifies details and existence of a bug before assign it to a developer)
* Confirmed - ticket confirmed by a reviewer and assigned to a developer
* Taken into Account - ticket read and taken into account by developer that will solve it as soon as possible
* Started/In Progress - ticket is in "work in progress" status
* Pending - ticket is commented by developer, assigned to reporter in order to receive more clarification on it; in this status responsibility of ticket is owned by Reporter
* Completed/Resolved - ticket is developed by a developer in its local machine for example but not delivered on an environment testable by reporter or by a tester. Is useful for a devoloper to know that he already solved but still not visible to customer.
* Delivered - solution of bug is delivered on a TEST environment in order to be tested by reporter, and ticket is assigned to reporter
* Closed - ticket is considered solved by reporter, closed and unassigned; this status should also hide ticket from main tickets list
We could add also other status for specific issues, for example:
* Clone - ticket is a clone of another one. Reviewer could set this status and automatically link it to the original one.
In order to manage not only bugs but also "Change requests", we could add the following status (many others are shared with previous ones):
* Quoted - CR asked in tickets is quoted by a developer (such as "1 day of work") and assigned back to customer in order to allow it to accept estimation and give ok to developing.
* Accepted - customer accepted estimation and assigned again to developer that will change ticket to "Taken into account" status.
Hi Simon, could be possible, because as I told you in another thread, I use to move to another project called "Completed Tasks", tickets already solved.Anyway, in this case something seems strange. As I wrote, ticket #14 exist in the project, but one linked by notification (with the same #) is unreachable. So, in my opinion if problem could be movement of original task #14 to another project, it should be always unreachable, both from notification link and from task list.
What am I missing? :-)
Thank you.
What am I missing? :-)
Thank you.
maybe this could remain an option in "customize" page. :-)
As written many times, I am completely favourable to improve "categorization" and "grouping tickets", so.... +1 for me.
Yes, but is not persistent! everytime I reload page, filters are dismissed
Servicio de atención al cliente por UserEcho
"
500
Oops! Something went wrong. We're working on getting this fixed as soon as possible."