MediaWiki-diskusjon:Gadget-show-sysop-activity.js

La til vasking av username for å fjerne et sikkerhetshull. — Jeblad 26. aug 2008 kl. 16:29 (CEST)

username = username.replace(/\s*\(.*?\)\s*/g, '');

Det bør legges til en avskjæring av prosesseringen om den igangsettes på sider i usannsynlige navnerom. Prosesseringen bør antakelig avbrytes i alle navnerom utenom «Wikipedia» og «Bruker». Dette skal inn i getSysopList(). — Jeblad 26. aug 2008 kl. 16:38 (CEST)

if (wgNamespaceNumber != /*bruker*/ && wgNamespaceNumber != /*wikipedia*/) return;

Update

Hi!

Could someone backport these updates to the script. They make the code more compatible with the recent version of MediaWiki and now it passes on JSHint validator.

Best regards, Helder.wiki 16. feb 2012 kl. 21:44 (CET)

Done, and thank you for your contributions. Stigmj 16. feb 2012 kl. 23:29 (CET)

N/A patruljeringstats

Pinger noen med peiling: Danmichaelo, Jeblad: Jeg har prøvd å fikse patruljeringsstatistikken (den viste «N/A»). Nå ser det OK ut, men jeg er litt usikker på hvor vellykket endringen egentlig er. API-kallet gir ikke lestart, men den gir lecontinue (som er i Mediawikis interne datoformat, ikke ISO). Det virker også som om informasjonen om autopatruljering ligger under params.auto, og ikke patrol.auto (dvs. params.auto eksisterer dersom det er autopatruljering, ikke på manuell patruljering). Jeg stusser litt over at API-en brått gir andre parametre enn før (lestart som ikke finnes, auto som er flyttet). Er dette kjente endringer? Parameteren rawcontinue la jeg til for å bli kvitt en warning fra APIen. --Chameleon (diskusjon) 4. mai 2015 kl. 16:44 (CEST)

Glimrende! Jeg kjenner ikke så godt til logevents, men vet at det har vært gjort en del arbeid med å standardisere pagineringsparametrene, så det virker rimelig at lestart har blitt erstattet. Den andre endringen virker også som en fornuftig standardisering. Men verdien i lecontinue er egentlig bare ment til bruk for å hente neste side, og det frarådes å bruke denne til noe annet (eller basere seg på at den skal ha et bestemt format), så vi bør kanskje se på om vi kan bruke verdien "timestamp"-verdien fra siste event. – Danmichaelo (δ) 4. mai 2015 kl. 17:50 (CEST)

Å benytte timestamp istedetfor lecontinue er en god idé, jeg prøver det i morgen. –leChameleon (diskusjon) 4. mai 2015 kl. 18:37 (CEST)

Hm, jeg så litt på det nå, men det var noe fishy her.. Hvis jeg forsto koden riktig virket det som paginering egentlig aldri har virket. Hvis ingen manuelle patruljeringer ble funnet returnerte processPatrolActionS() null, og patrol_handlerS() kalte processSysop() med en verdi i from. Men processSysop() gjorde bare nye API-kall hvis from evaluerte til false! Og det var ikke bare å kutte den sjekken heller, for da gjorde den jo plutselig 12 nye kall i stedet for ett… Jeg slang inn en nødløsning nå, men egentlig burde det vært gjort en ordentlig omskriving for å modernisere koden og redusere antall API-kall (som gjøres samtidig). – Danmichaelo (δ) 4. mai 2015 kl. 19:15 (CEST)

Dersom vi bruker timestamp må tsDate.setMW byttes ut med tsDate.setISO8601 (og funksjonen setMW kan fjernes). Jeg la til setMW fordi lecontinue bruker et eget datoformat. Men ja, du har rett i at noe er ikke helt i 100, jeg har aldri sett teksten «>1år til ∞»... --Chameleon (diskusjon) 4. mai 2015 kl. 19:25 (CEST)

Godt poeng, endra den. Hvis du sjekker nå får du opp «>1år til ∞» på én bruker, pluss at det er et par som får verdier nå som hadde "n/a" før. – Danmichaelo (δ) 5. mai 2015 kl. 00:09 (CEST)

Fritt fra minnet; du gir lestart (le er for log events) og får lecontinue tilbake. For å få neste side gir du lecontinue tilbake. Du bør ikke forvente noe spesifikt innhold i denne, slik som Danmichaelo. Sjekker du litt så vil du oppdage at denne har forskjellig innhold utfra hvilken opplysninger du ber om. Hvis du ber om flere opplysninger så må du page'e over alle datasett, dvs du må page'e inntil lecontinue blir tom. Hvis du bruker generatorer så kan det bli ganske uoversiktlig å få ned alle data. Du kan tilsynelatende hente ned en oppføring som er tom, for så å få dataene i senere nedlastinger. Egentlig er det ikke snakk om page'ing for data blir levert litt om hverandre. Kun hvis du bruker props er rekkefølgen på data forutsigelig, husker ikke helt når list er forutsigelig (mulig den alltid er det). Bruker du generator så er rekkefølgen på data sjelden forutsigelig.

Vær også obs på antall pipede argumenter i URL'en, har du mer enn 50 så blir overskytende forkastet uten feilmelding. — Jeblad 4. mai 2015 kl. 23:44 (CEST)