Instead of implementing the same thing (fetch all default options,
and if the option that we are looking for is in that array, return that
array entry, and if not, return null) in a bunch of places (DefaultOptionsLookup and StaticUserOptionsLookup do this directly,
UserOptionsManager just delegates to DefaultOptionsLookup) put
this implementation in the parent class
Change-Id: If66f806bc4839f6c1143c5e0adda726c6ed04aae
This includes fixing some mistakes, as well as removing
redundant text that doesn't add new information, either because
it literally repeats what the code already says, or is actually
duplicated.
Change-Id: I3a8dd8ce57192deda8916cc444c87d7ab1a36515
- Don't care about $queryFlags for anons since nothing can be
stored in the database for anons.
- For loading the options - discard the old cache in case higher
query flags are used. This means that 'setOption' has to by default
reload the options to ensure changing the options start from LATEST.
This codepath shouldn't be executed in reality cause we should
be already loading the user with READ_LATEST if we want to update
the options. Where that was not done - it was probably a bug.
Also, expose optional $queryFlags parameter for UserOptionsLookup
methods. Otherwise there's no way to read from master using public API.
Bug: T248527
Change-Id: Id7b9868ecdfba89bfafd4618365fe520ec59fcfe
This converts user options management to a separate
service for use in DI context.
User options are accessed quite early on in installation
process and full-on options management depends on the
database. Prior we have protected from accessing the DB
by setting a hacky $wgUser with 0 id, and relying on the
implementation that it doesn't go into the database to
get the default user options. Now we can't really do that
since DBLoadBalancer is required to instantiate the options
manager. Instead, we redefine the options manager with
a DefaultOptionsManager, that only provides access to
default options and doesn't require DB access.
UserOptionsManager uses PreferencesFactory, however
injecting it will produce a cyclic dependency. The problem
is that we separate options to different kinds, which are
inferred from the PreferencesFactory declaration for those
options (e.g. if it's a radio button in the UI declaration,
the option is of multiselect kind). This is plain wrong,
the dependency should be wise versa. This will be addressed
separately, since it's requires larger refactoring. For now
the PreferencesFactory is obtained on demand. This will be
addressed in a followup.
Bug: T248527
Change-Id: I74917c5eaec184d188911a319895b941ed55ee87
