New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Ask if user has contacting protecting admin before requesting unprotection #297

Open
wants to merge 4 commits into
base: master
from

Conversation

Projects
None yet
2 participants
@MusikAnimal
Collaborator

MusikAnimal commented Oct 26, 2015

It is procedural that users ask the protecting admin about unprotection before requesting it at [[WP:RFPP]]. More often than not this does not happen, so per request we're going to try to have Twinkle remind them.

In short: When the protection module is opened, you'll see the current protections as you do normally, but with the name of the protecting admin next to each entry, which links to their talk page. When you attempt to request unprotection you are prompted (with confirm) "Have you attempted to contact the protecting admins (MusikAnimal, NeilN) first?"

Some notes:

  • If an admin changes any protection settings they appear in the log as the admin responsible for all protection settings. E.g. if NeilN move-protects the page and I semi-protect it, it is not feasible to infer that NeilN did the move protection and not me. I don't think this is a big concern, as the re-protecting admin will have enough insight into why the other protections are there.
  • Protection settings can be moved when the page is moved. If the script detects the current protection was moved from a previous page, it will recursively go through the logs to find the original protecting admin. I believe there to be a rock-solid base case and graceful handling of failures so that the recursion won't lock up. Still working on this! Fixed... it now won't check logs that have already been checked. Otherwise it could go into an infinite loop when you protect a page, move it somewhere, then move it back to the original location.
  • Pending changes protection have their own log entry, but if moved from a previous page, it does not appear in the logs. This is a MediaWiki bug as far as I can tell, and the workaround to recurse through the page moves to find a pending changes log entry seems initially not worth the effort, but we may revisit it.
  • The interface shows the admin who applied the protections, as with "Current protections: Move: (sysop) ... by [link to MusikAnimal's talk page]". We have the sysop name next to each edit/move/create protect entry, even though they will be the same. This is purely for aesthetics, since it looks weird to have it just at the end. I also separated the entries by a bullet for better readability
    • A side note: What about a separate line for each entry, to make it even more readable? Or one line for edit/move/create protections and another for pending changes?
  • You are only prompted if you contacted the protecting admin if the script successfully figured out who the protecting admin was

Thoughts? I think this change is less than perfect but still effective, and will be well-received.

@atlight

This comment has been minimized.

atlight commented on modules/twinkleprotect.js in b1c1a1a Oct 26, 2015

Is data.query guaranteed to be non-null here? Just asking as I am not very familiar with mw.api.

@atlight

This comment has been minimized.

atlight commented on modules/twinkleprotect.js in b1c1a1a Oct 26, 2015

Please use

if ( ... ) {
  ...
}

style.

@atlight

This comment has been minimized.

atlight commented on modules/twinkleprotect.js in b1c1a1a Oct 27, 2015

Use \u2022

@atlight

This comment has been minimized.

atlight commented on modules/twinkleprotect.js in b1c1a1a Oct 27, 2015

Don't hardcode /wiki/. Use mw.util.getUrl

@atlight

This comment has been minimized.

atlight commented on modules/twinkleprotect.js in b1c1a1a Oct 27, 2015

Again, please spread these two lines a bit more. While we don't have firm rules on long lines, it is generally a pain to have lines like these with so much going on.

@atlight

This comment has been minimized.

atlight commented on modules/twinkleprotect.js in b1c1a1a Oct 27, 2015

So this seems to actually be returning a "promise" type object, not the protecting admin itself... So far we don't use these anywhere else in Twinkle, so it might be good to add a comment explaining what is going on.

@MusikAnimal

This comment has been minimized.

Collaborator

MusikAnimal commented Oct 27, 2015

Alright, after those last 2 commits I'm confident with what I have. I guess in my testing I got a little confused... turns out the logging API does report who actually applied pending changes protection, it just doesn't indicate it was transferred from a page move. As for the MediaWiki implementation this is probably the better way to do it, I guess (who cares whether it was moved).

Meanwhile tracking down who edit/move/create protected a page after it has been moved has long been a headache for users to figure out, so I guess that's a major bonus with this change to Twinkle. That is, one could open up the protect module only to see who applied the original protection. Pretty cool!

protect: CR concerns, jshint fixes
jshintrc: warn when using single-line blocks without curly braces
@MusikAnimal

This comment has been minimized.

Collaborator

MusikAnimal commented Oct 27, 2015

@atlight made the recommended changes, and also took the liberty of adding curly to the jshintrc. Thank you for your time!

@atlight

This comment has been minimized.

Collaborator

atlight commented Nov 1, 2015

Sorry, I'm very busy at present. I'd like to test this before merging, hopefully I will find time to do it soon.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment