danny.leinad wrote:

It doesn't make sense, if you introduce confirmation screen, there will 2 the same buttons:

• "Reject",
• "Undo".

Currently "Reject" button is very useful - it is improved version of "Rollback" button (you can automatically revert changes of all authors, not only of one author).

(In reply to comment #1)

It doesn't make sense, if you introduce confirmation screen, there will 2 the
same buttons:

• "Reject",
• "Undo".

Currently "Reject" button is very useful - it is improved version of "Rollback"
button (you can automatically revert changes of all authors, not only of one
author).

There is a lot of resistance to creating something that works like rollback, especially because of the multi-author nature of it. The fear is that good edits will get lumped in with the bad, and thus we'll lose edits and alienate new editors.

danny.leinad wrote:

If you do not want "create something that works like rollback", I do not understand why you created "Reject"... you have "Undo" with the same funcionality.

So I will try to propose a compromise solution:
Could you create two new permissions relating to "Reject" button:

• 'soft-reject' - similar to "Undo",
• 'hard-reject' - similar to "Rollback".

And 'hard-reject' permission should be assigned by default for 'sysop' group (the same as 'rollback' permission).

Plus communities will be able to request to enable 'soft-reject' or 'hard-reject' permission for 'editor' group.

(In reply to comment #3)

So I will try to propose a compromise solution:
Could you create two new permissions relating to "Reject" button:

• 'soft-reject' - similar to "Undo",
• 'hard-reject' - similar to "Rollback".

Maybe in the future, but not for the November release.

(In reply to comment #3)

So I will try to propose a compromise solution:
Could you create two new permissions relating to "Reject" button:

• 'soft-reject' - similar to "Undo",
• 'hard-reject' - similar to "Rollback".

No, we do not need more permissions for this. Nor should it act like rollback and be automatic. Since you are potentially affecting multiple users, a confirmation should be required.

danny.leinad wrote:

(In reply to comment #5)

No, we do not need more permissions for this. Nor should it act like rollback
and be automatic. Since you are potentially affecting multiple users, a
confirmation should be required.

I proposed *compromise solution*. 'hard-reject' would not be the default for all projects.

For example on Polish Wikipedia all editors have 'rollback' permission and a lot of people complaining that can't revert all unsighted changes using rollback.

Hi Leinad, I know you're trying to reach a compromise. It sounds like the Polish Wikipedia community has very different expectations surrounding how this feature should work than the English Wikipedia community does.

As I said before, we really don't want to make this an option for the November release. The reason is that I believe it's going to take an actual deployment of the feature to have an informed and inclusive conversation about what options should exist for the feature.

One thing we have tentatively planned after November is a fork of this extension into two: a "Pending Changes" variant where we strip away a lot of the complexity in the current codebase, and a "FlaggedRevs" version which is a continuation of the existing version. Once we do that, we'll be in a better place to actually talk about making this optional.

That said, I'm not sure making it optional is really the right thing to do. One reason why the code we have is so complicated is because we have so many options. Hence, there still will probably be resistance after November to adding a new option, but it may be the case that the FlaggedRevs fork can actually carry the default that you would like to see.

Created attachment 7741
v1 of reject confirmation

Work-in-progress on confirmation button. Currently brings you to the confirmation page, displays the information, and then goes nowhere when pressing OK.

attachment reject-patch ignored as obsolete

A few things I noticed:
i) Code is missing "$form .= Html::closeElement( 'form' );"
ii) Also missing "$form .= Html::hidden( 'target', $oldRev->getTitle()->getPrefixedDBKey() );"
iii) Also missing "$form .= Html::hidden( 'wpEditToken', $wgUser->editToken() );"
iv) I assume that $wgUser is just there for the quick version (the class field "user" might be better, or a User argument)

Created attachment 7753
v2 of reject button

Incorporated Aaron's feedback. Now fully functional, but ugly :)

Attached:

Committed in r75408 with one last minor fix.