Versions are changed in 8e940c4f21,
but that makes the version wrong
Follow-Up: I7f85d931d3b79da23e87b4e5692b2e14be8fcaa0
Change-Id: Iae43725b8e0fffc4d44bf57f6227334b41290bd9
Add a "global" parameter to ApiOptions which allows it to update or
override global preferences.
Bug: T323076
Depends-On: I686c0091768ed330683fff89201fae4f93b8a1c4
Change-Id: Ieb2d0c0d0da5c51b2a47ed8a967a47b4e7ad4577
Refactoring:
* Break out the database access part of UserOptionsManager to a separate
class hierarchy implementing interface UserOptionsStore. It's
basically a key/key/string-value store, very simple. The complex
parts of user options storage remain in UserOptionsManager.
* Bundle the UserOptionsManager caches into a per-user cache object. I
was adding a couple more and it was getting tedious.
Start integrating GlobalPreferences with UserOptionsManager:
* Have an array of stores. There's always a local store, and extensions
can add stores via an attribute.
* Add $global parameter to UserOptionsManager::setOption(), allowing
this method to update or override global options.
* Rename loadOptionsFromDb to loadOptionsFromStore.
* Move the local override feature from GlobalPreferences to core.
Bug: T323076
Change-Id: Ib3623b723557c819bc0ffdf21a4ffcb070eb298b
This is inconsistent with the access pattern of other constants in
MediaWiki. it's also confusing (e.g. it's unclear to a newcomer why
UserFactory is implementing IDBAccessObject) and it's prone to clashes
(e.g. BagOStuff class has a clashing constant).
It has been already announced: https://w.wiki/9DAX
Bug: T354194
Change-Id: Ic2357634b8385d65b55db2b557191419b06c40e0
User options saved to the database and retrieved get converted
to strings, but defaults and set but not yet saved vaues don't.
This behavior can be confusing.
When a value equal to the default is set for a given user, that
value won't be written to the database; defaults are represented
by the lack of a database row. This behavior can also be
confusing.
Update the phpdoc of some user preferences related methods and
variables to make these things clearer.
Change-Id: I32a18b30f007c97015e6d641379ce60ab6ac7ed7
Instead of calling self::READ_* on these constants, just directly call
it.
Since these classes are public and might be relied on directly in other
places, we can't remove the "implements IDBAccessObject" yet but we will
start doing that soon.
Bug: T354194
Change-Id: I3e26b9fc7f93efdfc55a1790a7cdfa5c0d562303
Why:
Sometimes, it is necessary to have different behavior
for newly registered and existing users. For example,
this happens in the Echo or GrowthExperiments extensions.
As of now, this behavior is implemented by inserting
user_properties rows in onLocalUserCreated.
Over time, this results in a singificant amount of rows
inserted, which contributes to the user_properties table bloat,
which is already overly large (cf. T54777). This patch makes it
possible to remove such rows by supporting conditional defaults
for user properties.
What:
Add support for conditional defaults of user properties. This can be
configured via `ConditionalUserOptions` config option.
Bug: T321527
Change-Id: I1549c3137e66801c85e03e46427e27da333d68e2
There are a couple of user options related classes already,
and the T321527 work on dynamic defaults is going to add
even more. Let's move them into a separate namespace
to make core a bit more organized.
Old name is kept as an alias for compatibility purposes.
Bug: T321527
Bug: T352284
Change-Id: I9822eb1553870b876d0b8a927e4e86c27d83bd52
2023-11-29 13:27:13 +01:00
Renamed from includes/user/UserOptionsLookup.php (Browse further)
