Commit graph

9 commits

Author SHA1 Message Date
jdlrobson c8642b2fbe Use feature management for search in header
This will allow us to add the A/B testing requirement for logged in
users.

In preparation for the new A/B test requirement, a custom requirement
is added as the feature management system does not
support OR operations and the desired effect is the case where:

* the SearchInHeader feature flag has been enabled
* OR the SearchInHeaderABTest feature flag has been enabled and the user is bucketed

Bug: T259250
Change-Id: If948603bd598e1b5597345f4268736417f4c3a24
2020-09-13 23:00:16 +00:00
jenkins-bot ec6307e669 Merge "[fix] "Existing account only" skin version config" 2020-04-29 18:55:30 +00:00
Stephen Niedzielski 709772fa12 [fix] "Existing account only" skin version config
de76ab5 added the config,
`$wgVectorDefaultSkinVersionForExistingAccounts`. Its usage in
`Hooks::onUserGetDefaultOptions()` was invoked not only for existing
accounts but anonymous users _as well._  This is a bug, due to my own
misconceptions about the hook, that went against both the config's name
and its documentation.

Unfortunately, user sessions are unavailable in
`Hooks::onUserGetDefaultOptions()` so it does not seem to be possible to
determine whether the active user is an anonymous or existing account.
This patch drops the hook and centralizes all version determination
logic in SkinVersionLookup::getVersion(). SkinVersionLookup requires a
the active User object and can make the anonymous / existing account
determination by checking login state.

The issued was identified while responding to review feedback given by
@polishdeveloper / @pmiazga in
I52d80942b4270c008d4e45050589ed9220255a50.

Bug: T251415
Change-Id: I7982b4c34283ba81d0232ee6f501c44cf0a74b98
2020-04-29 18:36:03 +00:00
Sam Smith d4c2e2b441 [Hygiene] featureManager: ComplexRequirement -> Requirement
FeatureManager::registerRequirement registering an instance of
SimpleRequirement with ::registerComplexRequirement was awkward.

Changes:

* Rename FeatureManager::registerRequirement to
  ::registerSimpleRequirement, which is exactly what it does!

* Rename FeatureManager::registerComplexRequirement to
  ::registerRequirement

Bug: T244481
Change-Id: I612af959cee4cdcd0bdcda51a81b86ed61ee2e16
2020-04-29 15:26:50 +01:00
Sam Smith cee5ee0003 Make legacy mode a feature
Changes:

- Add the LatestSkinVersionRequirement requirement class, which lazily
  evaluates the application state to get the version of the skin for the
  request.

  This majority of this class is taken from Stephen Niedzielski's
  Vector\SkinVersionLookup class, which was introduced in d1072d0fdf.

- Register an instance of LatestSkinVersionRequirement and register the
  'LatestSkin' feature that requires that requirement

- Re-introduce SkinVector::isLegacy and make it defer to the Feature
  Manager

Bug: T244481
Change-Id: If6b82a514aa5afce73e571abdd8de60b16a62fa8
2020-04-21 10:57:11 -06:00
Stephen Niedzielski 6b6bed86ed [docs] [dev] [PHP] [FeatureManager] revise docs and add DynamicConfigRequirement test
Address some feedback from I7a2cdc2dfdf20d78e4548f07cf53994563b234b3:

- Miscellaneous documentation improvements.
- Add a false case test to `DynamicConfigRequirement->isMet()`.

Bug: T244481
Change-Id: Ic5637f42da755f871c5a6d545e14effd3ac8c670
2020-03-26 20:39:40 +00:00
Sam Smith 84226b41b6 featureManager: Add DynamicConfigRequirement requirement
We expect the vast majority of requirements and features to be defined
in services as possible. However, there are some "complex" requirements
that require additional application/HTTP request state. Unfortunately,
service wiring is done before some of that state is available.

I65702426 attempted to work around this by requiring clients of the
Feature Manager to pass that additional state on every interaction with
the system. Those complex requirements would then select the parts of
the state that they required when it was required. However
implementations of \IContextSource are God objects and their use should
be limited.

Whilst reviewing I65702426, Stephen Niedzielski mentioned that the
application state being available is a requirement. This remarkably
simple solution:

- Keeps the Requirement interface and FeatureManager API free of God
  objects;

- Is true to the nature of the Feature Manager - it makes clear and
  centralizes the various checks for application state being available
  across the codebase; and

- Inject a Requirement implementations' dependencies at construction
  time

It just so happens that the $wgFullyInitialised variable flags whether
the application state is available...

Changes:

- Add the the FeatureManager\Requirements\DynamicConfigRequirement class
  and tests. The DynamicConfigRequirement lazily evaluates a single
  configuration value whenever ::isMet is invoked

- Register an DynamicConfigRequirement instance, configured to evaluate
  $wgFullyInitialised while constructing the Vector.FeatureManager
  service

Bug: T244481
Change-Id: I7a2cdc2dfdf20d78e4548f07cf53994563b234b3
2020-03-18 10:10:42 +00:00
Stephen Niedzielski de76ab59c1 [Special:Preferences] [PHP] Add skin version user preference and configs
Add a Vector-specific user preference to Special:Preferences for
toggling skin version, either Legacy Vector or the latest Vector.

The presentation of the new preference section and the default values
for anonymous, new, and existing accounts are configurable via
$wgVectorShowSkinPreferences, $wgVectorDefaultSkinVersion (to be used by
the feature manager in T244481),
$wgVectorDefaultSkinVersionForExistingAccounts, and
$wgVectorDefaultSkinVersionForNewAccounts. These configurations default
to the fullest experience so that third-party configuration is minimal.
See skin.json for details. The configurations are each tested in
VectorHooksTest.php.

When presentation is enabled, the new preference appears as a checkbox;
enabled is Legacy mode and disable is latest. There are a number of
unfortunate details:

- Showing and hiding a checkbox is supported by OOUI. Showing and hiding
  a whole section (Vector skin preferences, in this case) is not so this
  additional client JavaScript functionality is added in Core (see
  Iaf68b238a8ac7a4fb22b9ef5d6c5a3394ee2e377).
- Stylization as a checkbox is wanted. However, the implied storage type
  for OOUI checkboxes is a boolean. This is not wanted in the event that
  another skin version is added (e.g., '3' or 'alpha'). As a workaround,
  the preference is converted from a boolean to a version string ('1' or
  '2') on save in Hooks::onPreferencesFormPreSave() and from a version
  string to a checkbox enable / disable string ('1' or '0') in
  onGetPreferences(). There a number of test cases to help cover these
  concerning details.

Documentation for overriding the skin version as a URL query parameter
is provided in anticipation of T244481.

Bug: T242381
Bug: T245793
Depends-On: Iaf68b238a8ac7a4fb22b9ef5d6c5a3394ee2e377
Depends-On: Ifc2863fca9cd9efd11ac30c780420e8d89e8cb22
Change-Id: I177dad88fc982170641059b6a4f53fbb38eefad6
2020-02-26 12:56:10 -07:00
Sam Smith 9177c22365 features: Add minimalist feature manager
With complex additions to Vector's codebase like the Desktop Improvement
Program upcoming, it's important that we have a shared, intuitive
language to talk about features and their requirements. Centralising
the registration of features and creating an API satisfies does exactly
this.

This change introduces a greatly-reduced version of Piotr Miazga's
(polishdeveloper, pmiazga) original proposed API and associated
scaffolding classes for feature management in Vector, which itself was
based upon his work in MobileFrontend/MinervaNeue. This is done to
establish a foundation upon which we can build the more sophisticated
parts of Piotr's proposal in a piecemeal basis, thereby minimising risk.

Distinct from Piotr's proposed API is the ability to register sets and
features that are always enabled or disabled.

Additionally:

- A Vector.FeatureManager service is registered but not used

- A list of proposed immediate next steps is included

Bug: T244481
Change-Id: Ie53c41d479eaf15559d5bb00f269774760360bde
2020-02-26 11:49:29 +00:00