> We lose useful coverage and waste valuable time on keeping tags
> accurate through refactors (or worse, forget to do so).
>
> Tracking tiny per-method details wastes time in realizing (and
> fixing) when people inevitably don't keep them in sync, and time
> lost in finding uncovered code to write tests to realize it was
> already covered but "not yet claimed".
>
> Given all used methods are de-facto and liberally claimed, and
> that we keep the coverage limited to the subject class, this
> maintains the spirit and intent. PHPUnit offers a more precise
> tool when you need it (i.e. when testing legacy monster classes),
> but for well-written code, the class-wide tag suffices.
Ref https://gerrit.wikimedia.org/r/q/owner:Krinkle+is:merged+message:Widen
Change-Id: I89f510232554fddeaff90e264e3b396448623888
When rendering Special:RecentChanges for an user with rollback rights,
the software checks whether the user has permission to perform the
rollback action on each entry via User::probablyCan(), which
delegates to PermissionManager. This in turn checks for each entry
whether the title has protections (e.g. from action=protect) against the
"rollback" action, which is unlikely to be the case since by default
wgRestrictionTypes only supports create/edit/move/upload.
This triggers noticeable memcached I/O and overhead.[1]
So, as an optimization, avoid fetching page restrictions in
RestrictionStore for action types that are known to not be restrictable
via page protection. In the unlikely event that wgRestrictionTypes is
customised to offer separate restrictions for "rollback", this will
work continue to work as expected and is covered by tests.
-
[1] acd6281072/recentchanges.speedscope.json
Bug: T341319
Change-Id: I912e4ef2fa3d48238c01631d4f35940aea93ab03
Initally used a new sniff with autofix (T333745),
but some provide are defined non-static in TestBase class
and need more work to make them static in a compatible way
Bug: T332865
Change-Id: I889d33424f0c01fb26f2d86f8d4fc3de3e568843
Just methods where adding "static" to the declaration was enough, I
didn't do anything with providers that used $this.
Initially by search and replace. There were many mistakes which I
found mostly by running the PHPStorm inspection which searches for
$this usage in a static method. Later I used the PHPStorm "make static"
action which avoids the more obvious mistakes.
Bug: T332865
Change-Id: I47ed6692945607dfa5c139d42edbd934fa4f3a36
When creating ServiceOptions objects or fake HashConfigs use the
constant to refer the config name
Change-Id: I59a29f25b76e896c07e82156c6cc4494f98e64cc
WikiPage::doUpdateRestrictions only allows create protection for non-existent pages, so do not return upload as an available restriction for non-existent titles.
Bug: T298453
Change-Id: I5ed84a5a6213035afc9cc8710bb72bedfd9756ce
This allows checking restrictions without a dependency on Title, based
only on a PageIdentity.
Additional fixes along the way:
* Correctly return false instead of 'infinity' for
getRestrictionExpiry( 'create' ) on an existing page
* Correctly handle non-special pages that can't exist (like media pages)
in listApplicableRestrictionTypes() (return empty array instead of
'create')
* Improve readability of isProtected()
The expectation change in TitleTest::testIsProtected() is because the
test was formerly broken, since it set mRestrictions without setting
mRestrictionsLoaded. (Which illustrates how this approach to testing is
essentially broken.)
Co-authored-by: Vedmaka <god.vedmaka@gmail.com>
Bug: T218395
Change-Id: Ia73ea587586cb69eb53265b2f8f7a296a2573dd0
