Do you have some minimum code to reproduce this issue?
Bump any more work needed on this?
Can this be handled gracefully in Pywikibot?
@Pginer-WMF That looks like it would resolve at least most of the issues I have with the current set-up, and as long as it is obvious that truncation has happened when it has then there are no immediate problems with it I can see.
This is apparently due to a rights log event's content being hidden (revision deletion).
@Rammanojpotla - thank you very much for your help with this!
Change 410098 merged by jenkins-bot:
[mediawiki/extensions/PageForms@master] Enable all categories in Parent category drop-down
@MarcoAurelio: Unfortunately I'm not sure, sorry. :/ I could try looking around for evidence on MediaWiki.org (maybe that new repositories request page could help?) but I'm not sure where else I can find out. Hopefully someone from BlueSpice will be able to provide a more accurate answer.
@rosalieper - good catch! No, this task certainly isn't invalid - unless all those other calls to dieUsage() in Cargo have similar code around them. As for this code - I suppose the ideal solution would be to modify it to use the new helper function; although it would also work to just keep this code as it is and not change it.
"The drill-down interface provided by Amazon.com offers some interesting options: there, the filters and all their values appear in a sidebar, instead of at the top of the page - perhaps that should be the case for Special:Drilldown too?"
I renamed the hack script in tools.paws to paws-userhomes-hack.bash, it now looks like:
Here's my progress so far.
- Updated the wordlist page from the talk page (it's unclear what some of the template fields mean so ignored those)
- cloned editquality and revscoring on stat1005 (need to use the proxy and HTTPS Github URLs), ran pip install -r requirements.txt for both (in hindsight pip install -e might have been simpler)
- set up a venv, learned that the right way to do that on stat1005 is the virtualenv command (as opposed to python3 -m venv which will complain about missing packages and abort)
- updated editquality makefile along these lines. The patch is not super helpful in figuring out what to do:
- it does not use $@/$</$^, which seems to be the standard today
- it uses different parameters for revscoring calls (that seems to have changed with T173202)
- there are a bunch of random-seeming numbers (pop-rate, again coming from T173202) which are different for every wiki
- it's from before the makefile was split into a manual and a templated part (although huwiki is not templated so that wasn't too confusing).
However, I'm undergoing the same problems as Herzi pointed out one month ago. Any way to sort this out?
I'd say this is a pretty good working, yes.
Add the abusefilter-private and abusefilter-private-log rights to the set of rights held by the checkuser group
Add the abusefilter-private and abusefilter-private-log rights to the set of rights held by the ombudsmen group
Add the abusefilter-private-log right to the set of rights held by the steward global group
Add the abusefilter-private right to the set of rights held by the steward global group at Meta-Wiki only.
My advice is to do this off-SWAT. Talk to @greg and ask for a window to do 1 and then 2 (foreachwiki mwscript maintenance/purgeExpiredUserrights.php no matter how fast it is, will be run on 800+ Wiki and will take some time; and long-running scripts are always being run in their special windows afaik). As for 3, @Dzahn can review it and merge it on the puppet if 1 and 2 went well. Regards.
Okay so I don't know if my assumption is correct (most probably not!) but here's how I see things: $fe = SpecialPageFactory::getPage( 'FormEdit' ); so getTitle on SpecialPageFactory shouldn't output any warnings, right?. Then why changing $url = $fe->getTitle() to $url = $fe->getPageTitle() as proposed would fix it? I was looking at doing the proposed fix but declined to do so because I didn't saw it clear. I'd appreciate some explaining here. Thanks :-)
Marking as invalid. Feel free to reopen if someone can explain what is needed here.
Mentioned in SAL (#wikimedia-cloud) [2018-02-17T22:46:27Z] <zhuyifei1999_> # find /data/project/paws/userhomes/ -maxdepth 1 -user root | xargs chown -v tools.paws:tools.paws. Affected: 17295220 & 53267907 T185434
Hi, I've just created a new account (WikiLabMadrid) for giving a course on pywikibot to our local Spanish chapter. I wanted to show how to start using PAWS from scratch and, as my regular server is full of Python packages, created a new account. However, I'm undergoing the same problems as Herzi pointed out one month ago. Any way to sort this out?
Per @akosiaris: this seems to be how the software should behave and will probably not be accepted it taken upstream.
@Jalexander I also reviewed existing documentation:
@Jalexander: Here is a piece of text + some screenshots.