Okay, this rather harsh and unfriendly communication from a staff member already painted a bad picture. Now, we have this, which is totally unacceptable and amounts to global users with "superpowers" overriding a local community/admin action. That's two strikes. One more and I leave. This is not the behavior that I expect from the staff team from a service like this.
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
All Stories
Oct 10 2019
Sep 20 2019
Aug 11 2019
Jul 31 2019
Jul 29 2019
But... while all RevDel leaves a trace, there are two levels of RevDel. The "lower level" can be restored by anyone with the deletionrevision right, which by default is assigned to the sysop group (as on Wikipedia). The "second level" can only be restored or viewed by users with the suppressrevision right, which is what the WP:OS is.
No. Oversight is the group that remains at Wikipedia assigned the RevDel permissions. Oversight was an extension that used to leave no trace that was replaced by RevDel. All RevDel now leaves a trace and can be restored, all this information is on the WP:OS page you linked - however, this does not matter as we are not granting that right to users.
I'm sorry, but they are not the same thing.
They're the same thing. They use the same feature. We're not giving out rights to them, and we won't be "cleaning up" logs and history in future, unless there's a leak of personal information or libel as stated in the system message for RevisionDelete.
@jack thanks for the response.
ShoutWiki is indeed not consensus-operated and individual wikis' settings generally speaking need consensus only from the existing community (if any); "global consensus" just isn't something that's a thing over here.
Jul 27 2019
@jack bump!
Jul 25 2019
Been deployed for a number of months now with no issues.
So I played around with a few headers today, after giving Varnish most of Utter's RAM to play with. Pages at /wiki/ are currently cached for 10 minutes (we ought to maybe change this to be a little more namespace specific and/or exclude Special: pages?) and images for a month.
Jul 24 2019
Utter is now serving requests on all ShoutWiki sites. Will close task assuming no issues reported within the next few days.
Jul 18 2019
@znotch190711 If you aren't sure what projects to add a task to, don't. This isn't a task that requires a lot of code so it doesn't belong in Major Code. Also, stop the world and his wife to tasks. We've got systems that watch for new tasks so we can action them where necessary. What we don't have, is systems to go and clean all this junk from everyone's inboxes.
Jul 15 2019
We don't need CentralAuth, we already have a global user table. @jack developed the GlobalUserPage extension for ShoutWiki.
Jul 14 2019
Fine.
Except that I'm not asking for revision suppression. I'm asking for revision deletion. There are two different things.
I think it needs consensus from all ShoutWiki users to have the supressrevision right on Independent wikis.
I don't know who or what "Miraheze" is/was or what that has to do with this request.
I am a former Miraheze user, I do not think that it is possible. Maybe it could be restricted to SW staff.
Jul 13 2019
Jun 22 2019
Jun 21 2019
I'm going to close this as this is really more of something that has to be dealt with upstream - deleting accounts is something that MediaWiki doesn't handle in single wiki installations yet, so until an appropriate solution has been dealt with upstream for a single wiki, we can't really develop a way to do this without breaking wikis. You can read about this more on MediaWiki.org.
Jun 18 2019
Ref: osTicket#3336
May 2 2019
Apr 21 2019
Haven't done an in-depth review of the extension in question, although it would appear that the quality of BlueSpice extensions has significantly improved since I last took a look at one of 'em. Yay!
Hi @Brianna82 and apologies for the late reply!
Apr 11 2019
In T248#3826, @Brianna82 wrote:@jack Bump!
Mar 24 2019
Mar 21 2019
Yes, I use CMS on a website I own.
Mar 20 2019
In T251#3801, @PERCE-NEIGE wrote:Yes, I've read this warning (it's the same warning on Whitelist extension page). But how to do that?
T249:
nor is Phabricator appropriate for individual wiki setting requests. Please send an email to support@shoutwiki.com.
Yes, I've read this warning (it's the same warning on Whitelist extension page). But how to do that?
Mar 19 2019
If you need per-page or partial page access restrictions, you are advised to install an appropriate content management package. MediaWiki was not written to provide per-page access restrictions, and almost all hacks or patches promising to add them will likely have flaws somewhere, which could lead to exposure of confidential data.
Mar 16 2019
One thing I'd like to ask you right away: are these requests for all of ShoutWiki or for a single wiki? (If the latter, can you provide its URL/subdomain?)
Okay, thank you.
InstantCommons isn't an extension, nor is Phabricator appropriate for individual wiki setting requests. Please send an email to support@shoutwiki.com.
Hi @Brianna82, thanks for filing this request! One thing I'd like to ask you right away: are these requests for all of ShoutWiki or for a single wiki? (If the latter, can you provide its URL/subdomain?)
Pretty sure this got done ages ago as well.
This was done ages ago.
Down to one core hack, the AJAX page watching one, as of Q1/2019. Should really figure out a way to get rid of that and then Aurora would be a nice, stand-alone skin that requires no core hacks whatsoever...
DumpsOnDemand is old and abandoned and won't be revisited anytime soon.
LookupContribs v. 2.0 fixed this for LookupContribs, but as discussed on IRC, we'll need that schema change to the lookupcontribs table to be able to make MultiLookup use LC's dataset.
This is hopefully now done. It's not exactly the cleanest file out there, but...
Mar 14 2019
Mar 13 2019
Deployed - testing for a few days before cleaning up Brickipedia and closing as resolved.
NPM Tests are giving HTTP 500 errors. To investigate further at a later date.