In T324422#9982630, @Msz2001 wrote:

(but I didn't see the problem where the edits weren't done using VE).

In T368380#9982475, @Tgr wrote:

In T368380#9954488, @Tacsipacsi wrote:

Maybe another extension aborts a hook FlaggedRevs depends on?

At a quick skim I don't see any PageMoveComplete hook handler in Wikimedia production that would ever return false.

Maybe it should be test on Parsoid? Do we need $poutput stuff during autoreview?

In T368712#9948063, @Superpes15 wrote:

should I create a patch, or do you want to continue with your change?

OK, please continue.

Simply configure (one of logos and favicon are missing) as sysop-itwiki.

Negation is needed. And rules for visited redlinks, if applicable?

In T367638#9896494, @matmarex wrote:

So it seems that the account was treated as unregistered when creating the notification, and now there's bad data in the database.

Yes. Should isRegistered return true for global accounts (even no local created)? This needs to be checked also in light of forthcoming temporary accounts.

• Seems EchoEventPresentationModel.php $user->isRegistered() returns false for external (Wikibase) account. This account The monster is my thing ill do this if im thing is not registered on wikimaniawiki (and won't be).
• The agent name is truncated resulting in _ at the end which is invalid Title.

Something with https://www.mediawiki.org/wiki/MediaWiki:Gadget-tabbedwindow.js and latest heading structure modifications. What skins have this problem?

I can help with setting up on server if you (operators) need.

What do you see in network console?

@matmarex Could I have flag to allow all patches on Patchdemo?

But the message about translatewiki is still unparsed and not in interface language.

They had problems T363086 with deployment procedure and I don't know how they finalized it.

In T362856#9749363, @Msz2001 wrote:

The patch that @KartikMistry mentioned was deployed on 22 April to plwiki

No, from 23 to 25. Last event was 18:20, deployments are on 20:00 (in Poland)

In T362507#9747580, @Bluehill395 wrote:

The problem still occurs in 1.42. I think need to backport the changes.

This is related with the first section.
Maybe some delays, timeouts in getting version from some external software (CirrusSearch?).

We can delete getAssociatedNavigationLinks if we don't need it.

Now I created another entries on logs :P https://www.mediawiki.org/w/index.php?title=Topic:Xxavmfc41t2yb5zg&topic_showPostId=y3kaa7nq0w2z04tt#flow-post-y3kaa7nq0w2z04tt

_recheck

@Xaosflux works for you? If not, could you test network console?

For me it works.

Do you use any scripts (especially on translatewiki.net)?
Can it be from apihelp?

In T361041#9732668, @Ada_Jakubowska_WMPL wrote:

For your information, @AramilFeraxa and @SkrzydlatyMuflon will help us in the site creation process, so at the end of your job, when you create some accounts, you can also create accounts for them :)

Fixed by https://github.com/wikisource/api/commit/f98d1e57190507bfb977461d772a1dc4019a4b98

And T361622 at once. Always ignore main page title.

On Special:ListGroupRights make sure user group has writeapi right.

In T362139#9731305, @Msz2001 wrote:

In T362139#9724671, @matmarex wrote:

I'll be honest, I'm not sure how it's supposed to work. But I think I managed to restore how it worked.

I set up demo wikis to compare:
Before the bug: https://patchdemo.wmflabs.org/wikis/777f1587e8/w/index.php?title=Test1&action=edit&undoafter=152&undo=153
Current buggy version: https://patchdemo.wmflabs.org/wikis/1010d4fce1/w/index.php?title=Test1&action=edit&undoafter=152&undo=153
After the fix: https://patchdemo.wmflabs.org/wikis/83a92cb3f0/w/index.php?title=Test1&action=edit&undoafter=152&undo=153

If someone here feels like they understand it, I'd appreciate if you could test on those demo wikis as well.

@matmarex How can we test this? Do we have to get rights on these patchdemo wikis? (AFAIK, the accept checkbox does not appear if one does not have editor rights).

They click on rollback on history page or on diff view?

This may apply to wgContentTranslationUnmodifiedMTThresholdForPublish too?

Do another test

Maybe opted-out mentee has mentor that also opted out from being mentor.

The slash at the end is problematic. Removing it opens thread.

Maybe outdated issue.

• On mediawiki.org, where this thread is located, can see history (also logged out)
• On other wiki (Wikimedia) as Aklapper

Is preview of every deleted revision possible? And diffs between them?

Is it on your wiki or Wikimedia?
If your, you need to install Extension:JsonConfig and import also data from Commons or modify module to not use them or disable some of its features.

In T362139#9701584, @matmarex wrote:

@Wargo To clarify, you mean that getOldID() only checks whether we're viewing a page with the &oldid=… URL parameter, and we should also check for the &undoafter=…&undo=… parameters?

Yes, this is definitionof this function (method). Undo URL doesn't provide oldid.

This is because we check validity of URLs using wfParseUrlduring reading external links from flow_ext_ref but not during filling "reference" tables. This causes filling database with wrong links when they are inserted into messages (posts) and these alarms.

The only hook to fire update of watched heading's DOMs is ve.deactivationComplete.
Maybe it should be universal and VE should be modified to call the new hook?

Is any sense to call preprocessResults on empty set?

It happens only when list is empty - no subscriptions.

Thanks, I evaluated them again, and yes, this is the way.

In T275370#9708047, @Tacsipacsi wrote:

It looks like both I and @Wargo read the code as movestable and review. Movestable or review is okay.

Code says AND, regardless of what should be.

In T358743#9699281, @Nux wrote:

Confirmed to work on patchdemo :-)

Go to Special:UserRights and give your bot account "Editor" group or something else.
Yes, you can use Grants, but bot account must be allowed to use some of them.

if ( !$editPage->getArticle()->getOldID() ) { in 3ac6aa22cf8c4ef69272a15f5356ad5264d0e30c

Currently, user must have both review and movestable rights, not autoreview.

You need set $wgThanksLogTypeWhitelist to include stable. Your wiki can request this config change. Get a consensus and talk with server admins.

FlaggedRevs approve versions, not diffs. The version you would to approve has text made by changes of unapproved edits.

User must be also in group with this right. See Special:ListGroupRights, Special:UserRights.

What letter would be the best?

In T361940#9695650, @stjn wrote:

In T361940#9695592, @Ladsgroup wrote:

Doing this will address the problem for everyone regarding that issue: T359529#9684005

This is a massive change in how autoreview was handled though, if intended. Having one or multiple unreviewed templates on a page shouldn’t lead to requiring to review every single edit on a page.

Moving maybeMakeEditReviewed from RevisionFromEditComplete to PageSaveComplete in 8d1c5f81c976857fefaa30af69a536a2f27c2f3f is the cause.

Nadal aktualne?

I think helped the first solution...

Maybe RefreshImageMetadata.php on PL_JI_Kraszewski_Zygzaki.djvu would help?

What we know at the moment? What component is responsible for this? What was debugged? Any releated Tasks?

I've not seen this issue or reports about them.

Can't reproduce.
Maybe out of date.
Similar: T87111

Maybe another result of changes in T334263

Resolved. Gadget issue.

BTW. I noticed that pageoffset is also wrong:

Use as generator.
https://pl.wikisource.org/wiki/Specjalna:%C5%9Arodowisko_testowe_API#action=query&format=json&prop=proofread&list=&generator=proofreadpagesinindex&formatversion=2&gprppiititle=Indeks%3APL%20Dumas%20-%20Sylwandira.djvu

Changed webservice

Yes. It is not working. Impossible to set gadget loading only on editing if we want to add also to VE/NWE.

Last change broke permissionserrorstext-withaction, because messages such as MediaWiki:Action-protect are part of this.

And on monobook all the tabs (now on mediawiki.org)

Where is documentation of this issue? The returns make think it is not resolved.

Spot on betacluster.
monobook-action-move fallbacks to action-move but action-move has another purpose (see qqq)

It not created my account.

There should be more friendly message, both on User Interface and API if this is caused by query timeout. Currently it gives technical message.