Why:
* The maintenance script RemoveProtectedFlagFromFilter was added
to fix a mistake where a filter was 'protected' that shouldn't
be.
* There are certain steps that should be taken before and after
the script is run. These are not yet documented.
What:
* Document that the script should only be run after checking that
no data will be leaked.
* Document that a note should be left for filter editors to
explain when and why the script was run.
Bug: T380290
Change-Id: Iffe35c87782fdd499937565f1f8da62bfd36f93d
Why:
* Protected variables were introduced to support temporary accounts
so that temporary users could be filtered based on their IP address.
* Filters that use protected variables are protected in order to
preserve privacy. This can't be undone.
* It is mistakenly possible to protect a filter that does not use
protected variables (T378553). We need a mechanism to fix these
mistakes.
What:
* Introduce a maintenance script that takes a filter ID and, if the
filter is protected, sets it to unprotected while maintaining any
other existing privacy levels.
Bug: T378551
Change-Id: I4dfe3970221397d5be5ea0697490d8c8e3726adf
Why:
* Protected variables were introduced to support temporary accounts
so that temporary users could be filtered based on their IP address.
* Filters that use protected variables are protected in order to
preserve privacy. This can't be undone.
* The current workflow for protecting filters is to have a 'protect'
checkbox that can be checked for any filter, even one without
protected variables, to the discretion of the editor. This has
led to mistakes (see T37765).
What:
* Do not show the 'protect' checkbox on the form by default. Instead,
show it when saving a filter with protected variables, after form
submission. The user must check it to save the filter.
* Still show the checkbox in a disabled state with a warning message
if a filter is already protected, so that the editor can easily see
it is protected.
Bug: T377765
Change-Id: Ie5c94ac1399860ccdca4482508dd37ff07309764
Why:
* For improvements to the protected filters workflow (T377765),
a checkbox needs to be displayed conditionally on the status
of a previously submitted form.
What:
* Pass a status object into ::buildFilterEditor, and build the
HTML for any warnings or errors in that function, instead of
first building the HTML and passing it.
* This also allows more than one error and/or warning to be
shown if present, though this may not happen in practice yet.
Change-Id: I37da49711e7fc192856f013cd931c05379f8e8c6
Remove the use statement for MockAuthorityTrait, which is unused.
We can't use it because SpecialAbuseFilter checks permissions on
the user, not the authority.
Change-Id: I2baca5753dd9e21aa90b6856c5850d1100eda4d5
Why:
* The ProtectedVarsAccessLogger::logViewProtectedVariableValue
method creates a debounced log entry for accessing protected
variable values.
* This log can be created when a user calls the 'abuselog' query
API. This API query is made using a GET request.
* Because the ProtectedVarsAccessLogger creates the log
when it is called, the TransactionProfiler raises a warning
about writing to the primary DB on a GET request.
* We should address this warning by creating the log entry on
POSTSEND, in a similar way to how the CheckUser extension
creates CheckUser log entries.
What:
* Wrap the call to ProtectedVarsAccessLogger::log in
::logViewProtectedVariableValue with a DeferredUpdate callback
that is run POSTSEND.
** As part of this, the expectations that the code only uses the
replica DBs are silenced inside the DeferredUpdate as the
PostSend-GET expectations do not usually allow for writes.
The only other method would to be create the log via a job,
but we want the log creation to occur quickly and reliably.
Bug: T379083
Change-Id: If14e65b27b0bdd4fd0b99319024ffa281bf44656
- Clarify that to use protected variables in a filter, they must be
enabled and will cause the filter to be considered protected.
Bug: T377553
Change-Id: I69b879f12cfe76e6fff0080dd93024d6bd29159d
Conditional set of variable is not easy to read.
Instead set the variable to null before try/catch
Reported by a new phan plugin (2efea9f989)
This bypass a false positive from phan (T378271)
Change-Id: I037efe8465747b8c915405f38546fc1ea4405a03
Implicitly marking parameter $... as nullable is deprecated in PHP
8.4. The explicit nullable type must be used instead.
Bug: T376276
Change-Id: I303342cf1a002d5f0afc77ce147ce9453ea5282e
