migrateUserGroup.php should invalidate object cache and update user_touched for affected users
Closed, ResolvedPublic
Actions

Assigned To

Authored By

	Krinkle
	Sep 18 2012, 11:17 PM

Project Tags

Referenced Files

None

Subscribers

Krenair

Krinkle

Description

Object cache for users can contains users group data (User::saveToCache).

When constructing a User object and getting user groups (via User::getGroups, as done for Special:Listusers, Special:Preferences, API userinfo, mw.config, and user group permissions, pretty much everything) - and there is cache - it means changing user groups will be ineffective.

It will appear as though the user groups haven't changed at all. Just ran into this on a small wiki of mine, took a while to figure out that it was the object cache.

Version: unspecified
Severity: normal

Details

Reference: bz40340

Related Objects

Mentioned In: T42342: User::newFromId should not assume ID exists

Event Timeline

• bzimport raised the priority of this task from to Needs Triage.Nov 22 2014, 12:59 AM

• bzimport added a project: MediaWiki-Maintenance-system.

• bzimport set Reference to bz40340.

Krinkle created this task.Sep 18 2012, 11:17 PM

I was thinking of adding a simple loop that constructs a User object for the id, verify that the user exists by that Id, and then invalidate cache. But bug 40342 popped up.

Though not a problem right now because whether the account exists or not isn't that much of an issue because User::invalidateCache() makes sure load() is called and double-checks $this->mId again.

Fix in I22abdb.

Merged by Aaron Schulz on the 31st.

Krinkle mentioned this in T42342: User::newFromId should not assume ID exists.May 8 2017, 12:28 AM

migrateUserGroup.php should invalidate object cache and update user_touched for affected usersClosed, ResolvedPublicActions

Description

Details

Related Objects

Event Timeline

migrateUserGroup.php should invalidate object cache and update user_touched for affected users
Closed, ResolvedPublic
Actions