Last modified: 2011-03-10 21:01:38 UTC

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T29797, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 27797 - Don't let users set their own revisions to OK
Don't let users set their own revisions to OK
Status: VERIFIED FIXED
Product: MediaWiki extensions
Classification: Unclassified
CodeReview (Other open bugs)
unspecified
All All
: Normal enhancement (vote)
: ---
Assigned To: Nobody - You can work on this!
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2011-02-28 21:34 UTC by Chad H.
Modified: 2011-03-10 21:01 UTC (History)
4 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments
bleh (1.69 KB, patch)
2011-03-07 20:16 UTC, Sam Reed (reedy)
Details

Description Chad H. 2011-02-28 21:34:12 UTC
It's bad practice to review your own code.

CR should prevent people from setting their own statuses to "OK" or "Resolved"
Comment 1 Sam Reed (reedy) 2011-03-05 15:06:25 UTC
r83288
Comment 2 Antoine "hashar" Musso (WMF) 2011-03-07 18:59:32 UTC
Please also disable the option in the selection list :)
Comment 3 Sam Reed (reedy) 2011-03-07 19:32:45 UTC
That is obviously only doable for when you're viewing a specific revision, rather than doing it from the code review list view.. Ok? ;)
Comment 4 Sam Reed (reedy) 2011-03-07 20:16:14 UTC
Created attachment 8259 [details]
bleh
Comment 5 Sam Reed (reedy) 2011-03-07 20:19:36 UTC
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 ;)
Comment 6 Antoine "hashar" Musso (WMF) 2011-03-07 22:49:36 UTC
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
Comment 7 Sam Reed (reedy) 2011-03-07 22:53:56 UTC
Point still stands. The user needs to be able to select it

So disabling it is going to do nothing
Comment 8 Krinkle 2011-03-08 11:22:23 UTC
Also note that disabling on client-side is not solid, 

$('*[disabled]').removeAttr('disabled'); // :-P

Ignore this comment though, it's just paranoia.
Comment 9 Sam Reed (reedy) 2011-03-08 11:40:23 UTC
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
Comment 10 Krinkle 2011-03-08 11:47:47 UTC
(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 ;-)
Comment 11 Antoine "hashar" Musso (WMF) 2011-03-10 21:01:38 UTC
Got it, my request did not make sens.

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links