Why:
T367390 hid protected filters from users who didn't have the right to see them
because users with access to private filters also had access to search against
filters and were inadvertantly allowed to search against protected filters regardless
of whether or not they had the right to see them.
Now, in order to be consistent with how AbuseFilter displays private filters, reveal
protected filters to all users but continue to restrict access to their details.
What:
- Only hide protected filters when a user runs a search and doesn't have permission
to access them.
Bug: T381470
Change-Id: I2acb7e066885f6da18b29876c21c5d7d199b9886
Why:
* Filters should only be protected if they contain protected
variables, or have done in the past.
* Before T377765, it was possible to protect any filter, and at
least one filter was mistakenly protected.
* To check whether any other filters have been mistakenly
protected, it is helpful to run a query on all databases for
protected filters.
What:
* Add an option to maintenance/SearchFilters to allow searching
by privacy level.
Bug: T380290
Change-Id: I40837de7c63fb8001734df80524a0bf79ff50135
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
