:idna.encode/1 expects a charlist even though it will accept a binary string. That functionality is undocumented / not part of its typespec, so we should turn it into a charlist first. Also switch to using match?/2
lib/pleroma/user.ex:2056:call
The function call will not succeed.
:idna.encode(_host :: binary())
will never return since the success typing is:
(string()) :: string()
and the contract is
(string()) :: string()
Wrong @spec name for remove_from_block/2
lib/pleroma/user.ex:2721:overlapping_contract
Overloaded contract for Pleroma.User.add_to_block/2 has
overlapping domains; such contracts are currently unsupported and
are simply ignored.
This check was recently improved in Credo and it does make sense for readability.
The offending functions in Pleroma have been renamed and a couple missing the ? suffix have been fixed as well.
Rework inbound federation to accept requests optimistically. The HTTP Signatures Plug will not attempt to fetch the actor or key and will fail early.
If the signature cannot be validated we pass the required data into the Oban job with a reduced priority and increase the timeout to 20 seconds. The Oban job will handle the actor and key fetching before attempting to validate the activity again. This job will be retried 5 times by default.
Another welcome side effect is that actors who change their keys can federate to Pleroma instances immediately instead of needing to wait the default value of 86400s / 24 hours before the key will be fetched again.
Until now it was returning a 500 because the upload plug were going
through the changeset and ending in the JSON encoder, which raised
because struct has to @derive the encoder.
This fixes a race condition bug where keys could be regenerated
post-federation, causing activities and HTTP signatures from an user to
be dropped due to key differences.
I first focussed on getting things working
Now that they do and we know what tags there are, I put some thought in providing better names
I use the form <what_it_controls>_<what_it_allows_you_to_do>
:statuses_read => :messages_read
:status_delete => :messages_delete
:user_read => :users_read
:user_deletion => :users_delete
:user_activation => :users_manage_activation_state
:user_invite => :users_manage_invites
:user_tag => :users_manage_tags
:user_credentials => :users_manage_credentials
:report_handle => :reports_manage_reports
:emoji_management => :emoji_manage_emoji
This should eventually replace the Pleroma.User.all_superusers/0 function
* I added a new param `is_privileged` in User.query
* Now we can fetch all users with a specified privilege
This reverts commit 89667189b8 and cdc5bbe836.
This is a side effect when changing user role.
The goal was to not have report notifications when someone isn't admin or moderator any more.
But this won't be triggered when we change the privilege tags for a role, so we can't use this sollution any more.
There was another solution to filter out report notifications during fetch.
It wasn't merged because this seemed 'cleaner' at the time, but now it seems the better sollution.
I'll add it in the next commit.
Mark Felder