It appears that, currently, pruning occurs in file \ConfirmAccount\frontend\specialpages\actions\ConfirmAccount_body.php

# Every 30th view, prune old deleted items
if ( 0 == mt_rand( 0, 29 ) ) {
ConfirmAccount::runAutoMaintenance();
}

Therefor, the function runAutoMaintenance appears to be the pruning function. runAutoMaintenance lives in \ConfirmAccount\backend\ConfirmAccount.class.php

class ConfirmAccount {
/** * Move old stale requests to rejected list. Delete old rejected requests. */
public static function runAutoMaintenance() {...

In order to call runAutoMaintenance after every reject-action, I think the call to runAutoMaintenance should be placed in function rejectRequest, in file \extensions\ConfirmAccount\business\AccountConfirmSubmission.php

Specifically, i think it can go directly under:

# Clear cache for notice of how many account requests there are
ConfirmAccount::clearAccountRequestCountCache();

Maybe pruning should also happen after Accept, Hold, and Spam actions. Unsure. For now, pruning after Reject should handle the OP.

I attempted the above fix, and it did not seem to work. I'm at a loss.

Can someone determine why this fix did not work?

Original code:

protected function rejectRequest( IContextSource $context ) {
....
# Clear cache for notice of how many account requests there are
ConfirmAccount::clearAccountRequestCountCache();
....

New code:

protected function rejectRequest( IContextSource $context ) {
....
# Clear cache for notice of how many account requests there are
ConfirmAccount::clearAccountRequestCountCache();
# Prune
ConfirmAccount::runAutoMaintenance();
....

How i'm testing this:

• install ConfirmAccounts.
• Request an account.
• Login as admin, and reject the request. Then logout.
• Request again with same email.
• Receive "Username is already in use in a pending account request."
• Then insert new line of code into function rejectRequest (as above).
• Then test again, with a different email.
• On 2nd request, still getting "Username is already in use in a pending account request."

Hey @Johnywhy

just saw, that you missed the IRC meeting yesterday and wanted to check if you're good. Since this ticket is resolved I guess you are. Don't hesitate to ask questions in the IRC channels even outside of the advice hours. Also you could always use https://discourse-mediawiki.wmflabs.org/ to discuss issues.

best,
Fisch

Thx Fisch. How did you know i missed the meeting? You guys are strict :D
I developed a php solution, explained above.
Indeed, i got a clue from an ancient Greek on the IRC :)

cheers
jw

Is the info i added here good and correct?
https://www.mediawiki.org/wiki/Extension:ConfirmAccount#Pruning_Frequency

thx

@Johnywhy: You could remove duplicated empty lines (see the difference in the preview), and not use bold text for some file name/path? You could also either use <syntaxhighlight lang="php"> instead of <code>, or even better remove "old code" and "new code" sections and just describe which specific <code>line</code> to add after which existing line. I'm also wondering if there is some less complicated word than "prune" which I had to look up?

In T190343#4087115, @Aklapper wrote:

@Johnywhy: You could remove duplicated empty lines (see the difference in the preview), and not use bold text for some file name/path? You could also either use <syntaxhighlight lang="php"> instead of <code>, or even better remove "old code" and "new code" sections and just describe which specific <code>line</code> to add after which existing line. I'm also wondering if there is some less complicated word than "prune" which I had to look up?

Many thx for feedback!

• IIRC, the <code> tag caused extra blank lines. Your syntaxhighlight tag fixes that. Thx!
• a filepath is like code-- should have a different format, to improve clarity, so reader knows where text ends and filepath begins, improving understandability. The backtick doesn't work there, for inline code, but code tag does, thx for that! (is there a way to make backtick work in mediawiki?)
• 'old code' and 'new code' sections helps readers see the key differences, improving understandability. i understand code better when see the code in context, not just a "description". i provided both for max clarity.
• "prune"
  • a very common word. The sentence "Prune old items" has a Readability Score of A, and Dale–Chall readability rating of "easily understood by an average U.S. 5th or 6th-grade student." https://readable.io/text/
  • "Prune" is already used in the helpfile and the source-code.

Re functionality, will this mod break if the extension is updated?

@Johnywhy: Thanks for the readable.io reference, didn't know about that one! My comments on duplicated unneeded empty lines and the file path being bold (you could use <code> instead) remain valid.

@Aklapper : thx, see my revised comment above.

full steps to mod the extension here:
https://www.mediawiki.org/wiki/Extension:ConfirmAccount#Pruning_Frequency

Pruning is broken for PostgreSQL:

Jan 10 22:55:14 db postgres[3239]: [8-1] ERROR:  insert or update on table "account_requests" violates for
eign key constraint "account_requests_acr_user_fkey"
Jan 10 22:55:14 db postgres[3239]: [8-2] DETAIL:  Key (acr_user)=(0) is not present in table "mwuser".
Jan 10 22:55:14 db postgres[3239]: [8-3] STATEMENT:  UPDATE /* ConfirmAccount::runAutoMaintenance 2A05:3580:D200:... */  "account_requests" SET acr_rejected = '2019-01-10 13:55:14 GMT',acr_user = '0',acr_comment = '(this request has automatically been discarded due to inactivity)',acr_deleted = '1' WHERE (acr_rejected IS NULL) AND (acr_registration < '2018-12-11 13:55:14 GMT') AND (acr_held < '2018-12-11 13:55:14 GMT' OR acr_held IS NULL)