It's bad practice to review your own code.
CR should prevent people from setting their own statuses to "OK" or "Resolved"
Version: unspecified
Severity: enhancement
• demon | |
Feb 28 2011, 9:34 PM |
F7602: new.patch | |
Nov 21 2014, 11:29 PM |
It's bad practice to review your own code.
CR should prevent people from setting their own statuses to "OK" or "Resolved"
Version: unspecified
Severity: enhancement
That is obviously only doable for when you're viewing a specific revision, rather than doing it from the code review list view.. Ok? ;)
Got a problem here. If we remove the ok status, and the user then saves it (after it's been set ok by someone else), to add another comment, that'll change the revision status, purely based on how CR attempts to save things.
Re-closing bug.
I'm not reconfiguring the whole of CR to stop this ;)
I was talking about disabling the HTML option in the HTML selection list!
Example:
http://www.w3schools.com/tags/tryit.asp?filename=tryhtml_option_disabled
Point still stands. The user needs to be able to select it
So disabling it is going to do nothing
Also note that disabling on client-side is not solid,
$('*[disabled]').removeAttr('disabled'); // :-P
Ignore this comment though, it's just paranoia.
Unless I'm loosing it, my original point still stands, doesn't it?
If we disable something in the combo box, the user can't keep it selected, so without coding round it, and I mean, how do we know the author didn't want to set it to fixme later? And hence, we'll get changing statuses for no reason
(In reply to comment #9)
Unless I'm loosing it, my original point still stands, doesn't it?
If we disable something in the combo box, the user can't keep it selected, so
without coding round it, and I mean, how do we know the author didn't want to
set it to fixme later? And hence, we'll get changing statuses for no reason
AFAIAC, your point stands. I didn't reopen the bug ;-)