While "is_active" is a property of users, it is not a recognised keyword
for the User.Query helper; instead "deactivated" with negated value must
be used.
This arose because originally the user property was also called
"deactivated" until it was renamed adn negated five years ago
in 860b5c7804. This included renaiming
the parameter in most but not all User.Query usages.
Notably the parameter in User.get_followers_query was renamed
but not in User.get_friends_query (friends == following).
The accepted query parameter in User.Query however was not changed.
This lead to the former mistakenly including deleted users causing
too large values to be reported in the ActivityPub follower, but not
following collection as reported in #1078.
In Masto API responses filtering by `User.is_visible` weeded out
the extra accounts before they got displayed to API users.
On the surface it might seem logical to align the name of the User.Query
parameter with the actual property name. However, User.Query already
accepts an "active" parameter which is an alias for limiting to accounts
which are neither deleted nor deactivated by moderators (both indicated
by is_active) and also are not newly created account requests still
pending an admin approval (is_approved) or necessary email confirmation
(is_confirmed); in short as the alias suggests whether the account is
active. Two highly similar parameter names like this would be much too
confusing.
The renamed "is_active" on the other hand does not actually suffice to
say whether an account is actually active, only whether it has (not yet)
ceased to be active (by its own volition or moderator action).
Meaning its "new" name is actively misleading. Arguably the rename
made things worse for no reason whatsoever and should not ever have
happened.
For now, we’ll just revert the incorrect query helper parameter renames.
Fixes: https://akkoma.dev/AkkomaGang/akkoma/ issues/ 1078
(cherry picked from commit a899663ddc0e3a2084a239eabd79608a94ac5493)
This standardizes this functionality within the Search module so
it doesn't need to be imported by other search backends from Meilisearch
Also integrate its filtering rules into Search.indexable?/1 for consistency
warning: :warnings_as_errors is deprecated as part of Code.get_compiler_option/1
(elixir 1.18.3) lib/code.ex:1597: Code.get_compiler_option/1
(elixir 1.18.3) lib/code.ex:1572: anonymous fn/2 in Code.compiler_options/1
(elixir 1.18.3) lib/enum.ex:2546: Enum."-reduce/3-lists^foldl/2-0-"/3
(elixir 1.18.3) lib/code.ex:1571: Code.compiler_options/1
(pleroma 2.9.1-77-g8ec49c59-elixir-1-18+test) lib/pleroma/application.ex:104: Pleroma.Application.start/2
(kernel 10.2.6) application_master.erl:295: :application_master.start_it_old/4
warning: :warnings_as_errors is deprecated as part of Code.put_compiler_option/2, instead you must pass it as a --warnings-as-errors flag. If you need to set it as a default in a mix task, you can also set it under aliases: [compile: "compile --warnings-as-errors"]
(elixir 1.18.3) lib/code.ex:1710: Code.put_compiler_option/2
(elixir 1.18.3) lib/code.ex:1573: anonymous fn/2 in Code.compiler_options/1
(elixir 1.18.3) lib/enum.ex:2546: Enum."-reduce/3-lists^foldl/2-0-"/3
(elixir 1.18.3) lib/code.ex:1571: Code.compiler_options/1
(pleroma 2.9.1-77-g8ec49c59-elixir-1-18+test) lib/pleroma/application.ex:104: Pleroma.Application.start/2
(kernel 10.2.6) application_master.erl:295: :application_master.start_it_old/4
lib/mix/tasks/pleroma/emoji.ex: The tuple {:cwd, pack_path} on line 114 is expected to have type :cooked
| :keep_old_files
| :memory
| :verbose
| {:cwd, list(char())}
| {:file_filter, (record(:zip_file) -> boolean())}
| {:file_list, list(:file.name())} but it has type {:cwd, binary()}
lib/mix/tasks/pleroma/instance.ex:356:pattern_match_cov
The pattern
:variable_
can never match, because previous clauses completely cover the type
%{
:anonymize => boolean(),
:dedupe => boolean(),
:read_description => boolean(),
:strip_location => boolean()
}.
