Flyspray - The bug killer!

“If debugging is the process of removing bugs, then programming must be the process of putting them in.” – Edsger Dijkstra

This is the Bug Tracking System for the Flyspray project. This is not a demo! Before opening a new task, please read the guidelines!

Do not issue bugs reports against versions earlier than 0.9.9.5

Security problem? Check the security section.

Tasklist

FS#1203 - tasklist displays wrong status

Attached to Project: Flyspray - The bug killer!
Opened by Pierre Joye (Pierre) - Saturday, 24 February 2007, 16:13 GMT+1
Last edited by Florian Schmitz (Floele) - Monday, 26 February 2007, 07:20 GMT+1
Task Type Bug Report
Category User Interface
Status Closed
Assigned To No-one
Operating System All
Severity Low
Priority Normal
Reported Version 0.9.9
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No

Details

A bug assigned to me is still displayed as “new” in the tasks list.

list:
http://bugs.libgd.org/?project=2&do=index

details:
http://bugs.libgd.org/?do=details&task_id=48

This task depends upon

Closed by  Florian Schmitz (Floele)
Monday, 26 February 2007, 07:20 GMT+1
Reason for closing:  Works for me
Comment by Pierre Joye (Pierre) - Saturday, 24 February 2007, 16:21 GMT+1

Chirstian, you can fetch the DB in your “home” (20070224 file). The code is a clean 0.9.9 install.

Comment by Florian Schmitz (Floele) - Saturday, 24 February 2007, 17:48 GMT+1

Well, it depends on how that task was assigned. The status will only change to “assigned” if the task has been “new” or “unconfirmed” before. Also, if you edit the task and add an assignee, the status will not change. It will only change if you push “Assign to me” or “Add me to assignees”.

And a note: This feature will be removed in 1.0 since you could even remove the status field and we thus can’t hardcode features like that.

Comment by Pierre Joye (Pierre) - Saturday, 24 February 2007, 19:45 GMT+1

One task was new, the other was created with an assignee directly. The later fits in your description and makes sense, the sooner sounds like a bug.

As a sidenote, I proposed to Christian to move all fields but the reporter (the left part of the header) outside the “edit this task” mode. Changing these fields are part of the issue life cycle and it is a bit annoying to have to edit the task to change something, especially once I already wrote a complete comment :)

Comment by Florian Schmitz (Floele) - Saturday, 24 February 2007, 20:25 GMT+1
One task was new, the other was created with an assignee directly.

The second one will not auto-change, the first one will not if you changed the assignees during edit mode and not using the buttons. In any case you shouldn’t be too concerned when the feature won’t stay long anyway ;)

As a sidenote, I proposed to Christian to move all fields but the reporter (the left part of the header) outside the “edit this task” mode.

Huh? “left part of the header” is what? And the reporter-field? I only know a reported version field. And Christian didn’t tell me yet. Since I’m currently working a lot on the fields, it might be useful if you told me as well.

Comment by Pierre Joye (Pierre) - Saturday, 24 February 2007, 20:37 GMT+1

“Huh? “left part of the header” :”

Category and Task Type can remain in the “edit this task” mode but the following fields should be editable when a developer post a comment:

  • Status Unconfirmed
  • Assigned To
  • Operating System
  • Severity
  • Priority
  • Reported Version
  • Due in Version
  • Due Date
  • Percent Complete
  • Votes
  • Private
  • Watching

It is handy to do all changes in one post or action.

Comment by Florian Schmitz (Floele) - Saturday, 24 February 2007, 20:44 GMT+1
  • Field changed: Status (Unconfirmed → Researching)
  • Field changed: Category (Backend/Core → User Interface)

Well, you can in fact edit the task and add a comment at the same time. You can’t add a comment and edit a task though. This comment is an example.

Comment by Pierre Joye (Pierre) - Saturday, 24 February 2007, 21:27 GMT+1

Yes, it is possible to do it, but I have to first select the bug and then edit the details. But adding a comment and changing one of this field are common operations, they should be possible straight away for a developer (or higher) user. It is more user friendly to have a way to select a bug, reply to a question and set the correct status directly.

Comment by Florian Schmitz (Floele) - Saturday, 24 February 2007, 23:08 GMT+1

Well, it might be that we will use some AJAX later to make fields editable on the fly. Maybe we can also use the syntax for  FS#961  in comments.

Anyway, what about your problem? How has the task been assigned? Or is it clarified now?

Comment by Pierre Joye (Pierre) - Saturday, 24 February 2007, 23:20 GMT+1

It is clarified for the 2nd case, but not really for the first case. I find the behavior rather confusing. Is it possible to compare the current values against the new values, generate a diff and raise the appropriate events? No matter which field are modified or which actions have been taken. Such method can then be used to send one mail per person for each set of actions, instead of many mails about the same set of changes (ie: I edit a bug, change a field or two but got a comment and details mail). That’s what I like in our rudimentary bugs system on php.net or in phpbt.

About making them editable with ajax, it is not required. I add a comment, change some fields, submit everything with a “Submit all”-like button, simple, efficient :)

The syntax uses in a mail system is too tricky in my opinion for the web interface, however FS will be even better with a mail interface. By the way, its syntax should be customizable as one can come from an existing and/or has to keep the existing rules.

Comment by Florian Schmitz (Floele) - Sunday, 25 February 2007, 00:14 GMT+1
Such method can then be used to send one mail per person for each set of actions, instead of many mails about the same set of changes (ie: I edit a bug, change a field or two but got a comment and details mail).

That’s quite a different task now. But it will probably be addressed in 1.0.

I add a comment, change some fields, submit everything with a “Submit all”-like button, simple, efficient :)

Can you explain me how you want to edit a task without using the edit task page and without using AJAX?

The syntax uses in a mail system is too tricky in my opinion for the web interface

You didn’t even see it yet, how can you tell it’s too tricky?

By the way, its syntax should be customizable as one can come from an existing and/or has to keep the existing rules.

No. That would really be nothing but over-optioned.

Comment by Pierre Joye (Pierre) - Sunday, 25 February 2007, 01:09 GMT+1

“Can you explain me how you want to edit a task without using the edit task page and without using AJAX?”

Example: I like to add a comment to a bug, assign it to me, change the category and sevirity.

What happens too often is that I first start to add a comment and then think about this “Edit task”. It happens to other reporters as well. Then I don’t want to change the initial report (edit the original task), I like to update its properties and that’s an history event.

But if I don’t forget, the ops will be:
- select the task
- click “edit details"
- click “add a comment"
- write my comment
- change the fields as required
- submit

What I would like is (as a developer of a given project):
- select the task
- add a comment
- change the fields as required
- submit

About ajax, I did not say I do not want to use ajax. I only find ajax useless for this exact case (outside the assignee auto complete and other nice ajax usages).

“You didn’t even see it yet, how can you tell it’s too tricky?”

Anything more than a click is trickier for me, but that’s a taste matter. Or to say it differently, I’m not sure how a special syntax in the text comment would help here :)

“No. That would really be nothing but over-optioned.”

Is it possible to do not be loud. I’m not blind and you are not making your point clearer. But point taken, you will not make it customizable, no problem here.

Comment by Florian Schmitz (Floele) - Sunday, 25 February 2007, 11:18 GMT+1
What I would like is (as a developer of a given project): - select the task - add a comment - change the fields as required - submit

Now that is the point where I can’t follow your ideas. After “add a comment”, how to you intend to “change the fields as required”? If the comment is already done, and you don’t want to go to the edit task page I don’t see how you can automagically change fields. Changing fields requires an action. And you don’t tell me which one ;)

Is it possible to do not be loud. I’m not blind and you are not making your point clearer.

It’s not being loud, it’s emphasis. When I see such oversized feature requests I’m always a little disappointed because people always want more and more and more without apparently ever being happy with the stuff they have. I still remember some of those feature requsts here...

Comment by Pierre Joye (Pierre) - Sunday, 25 February 2007, 13:07 GMT+1
Now that is the point where I can't follow your ideas. After "add a comment", how to you intend to "change the fields as required"?
If the comment is already done, and you don't want to go to the edit task page I don't see how you can automagically change fields. 
Changing fields requires an action. And you don't tell me which ;)
If I’m a developer (or with similar permissions), it would be nice to be able to have the fields (listed in a previous comment) and the comment text area directly editable when I watch a bug. The changes in the fields and my new comment can be submitted using one single “submit” button. I hope I’m more clear now :)
Comment by Florian Schmitz (Floele) - Sunday, 25 February 2007, 13:41 GMT+1

Ah, so you want it to be like in BugZilla where the task fields are always selects/input boxes even when you view the task? Well, I see some problems with that. The most important one is that you cannot submit a comment and a task form at the same time because both is in a different form. We can’t simply put the whole page in a single form. That’s why I suggested to use AJAX. You then don’t have to go to the edit task page, but you could transform the fields you view on the details page into selects/input boxes without loading a new page.

BTW, quoting works like that:

My quote

My answer

Comment by Pierre Joye (Pierre) - Sunday, 25 February 2007, 15:22 GMT+1
The most important one is that you cannot submit a comment and a task form at the same time because both is in a different form.

Good point, it looks tricky to change and it may be a bad idea to do it before 1.0.0.

That’s why I suggested to use AJAX. You then don’t have to go to the edit task page, but you could transform the fields you view on the details page into selects/input boxes without loading a new page.

As long as I can submit the comment and the changes with one click, it is perfect :) The idea is to submit the changes and the comment in one operation/action not to dynamically change each field (especially not if each single change raise a notify event).

thanks for the quote, I was trying all possible syntax, add a icon? :)

Comment by Florian Schmitz (Floele) - Sunday, 25 February 2007, 22:49 GMT+1

Is this what you are looking for? Shot taken from Trac.

Comment by Pierre Joye (Pierre) - Sunday, 25 February 2007, 23:14 GMT+1

exactly :)

Comment by Florian Schmitz (Floele) - Monday, 26 February 2007, 07:19 GMT+1

Ok. I’ll close this task now because there doesn’t seem to be any bug (checked in branch again - if you add an assignee when editing a task, the status will and should not change automatically) and because it won’t exist for long anway.

Loading...