https://bugzilla.wikimedia.org/show_bug.cgi?id=20290

--- Comment #28 from Alex Monk <kren...@gmail.com> ---
(In reply to comment #27)
> Hold on, Alex. What commit are you talking about? I don't see any links to
> commits on this bug report. Even if I did, please keep in mind that we have
> different skillsets, and I am not a developer and cannot read code or really
> understand anything in Gerrit. I'm here as an oversighter, one of the handful
> of active oversighters who has worked with both the oversight extension and
> the
> revision-deletion/suppresion extension.  So tell me: how *does* the proposed
> script deal with oversighted revisions to now-deleted pages? The way the
> script
> is described here, it appears to be intending to reinstate all revisions,
> which
> logically would mean that it would have to recreate the previously-deleted
> pages.  And how would we track whether or not logs need changing? Remember
> that
> revdeletion/suppresion doesn't automatically result in revdel/suppression of
> all log entries.

The debate going on here is over whether this feature request (allowing
suppression to completely hide the existence and timestamp of a revision - for
old OS'd revisions anyway) should be solved before the commit on bug 18598 is
approved. That bug is about making a script to automatically convert all
revisions in Oversight's 'hidden' table to properly suppressed edits. And yes,
I'm sorry, I will try to explain what was wrong:

(In reply to comment #25)
> If they are moved to revision deletion alone, without suppression, then yes
> there will be hundreds of people who suddenly have access.

* Suppression is a part of RevisionDelete. The current version of the
conversion script applies suppression - full hiding from admins as well as
unprivileged accounts.

(In reply to comment #25)
> There are
> also problems when the suppression was done on pages that were subsequently
> deleted, because it will recreate those pages

No, it can tell that a page no longer exists and will place the new revision in
either 'revision' or 'archive' (the table where page-deleted revisions get
moved to).
(This is based on the page's ID rather it's title, therefore I believe there
shouldn't be any issues if that page title later has been recreated/restored -
the new page will have a different ID and therefore the OS'd revision should go
to the archive.)

(In reply to comment #25)
> creating a tool that allows oversighters to do this would be more reasonable
> than an automated, unmonitored process that will suddenly return large
> amounts
> of information to the publicly accessible revision table

The public views of the revision table do not allow access to suppressed
information - the hidden fields just appear to be NULL. If they did that would
be a huge security issue, but obviously not related to this script. I am
unaware of any risk relating to storing suppressed/OS'd data in the revision
table (it's definitely already being done).

-- 
You are receiving this mail because:
You are the assignee for the bug.
You are on the CC list for the bug.
_______________________________________________
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l

Reply via email to