| Age | Commit message (Collapse) | Author |
|---|
|
Everything now happens with privileged?/2
|
|
Before we deleted the notifications, but that was a side effect and didn't always trigger any more.
Now we just hide them when an unprivileged user asks them.
|
|
This reverts commit 89667189b840fc79d85336739e6b2512684d7be0 and cdc5bbe8369d4fc66d642bb3e845a237d11e34d7.
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.
|
|
According to the tests, this was only used for unconfirmed accounts.
So this just needed to be restricted to users with privilege :user_activation
|
|
superuser
|
|
Instead of superusers, you now need a role with privilige :status_delete to delete other users statusses
I also cleaned up some other stuff I saw
|
|
This should eventually replace Pleroma.User.superuser?/1
|
|
Fixed the warning
[warning] Please change `clear_config([section], key: value)` to `clear_config([section, key], value)`
|
|
I still had three endpoints I didn't really know what to do with them. I added them under separate tags
* :instance_delete
* :moderation_log_read
* :stats_read
I also checked and these are the last changes done by MR https://git.pleroma.social/pleroma/pleroma/-/merge_requests/3480/diffs this is trying to fix
|
|
|
|
It also allows to update a message, so it's not just deleting. I need a better name...
|
|
From the endpoints left to do, I believe these should be under :statuses_read.
These should be the last for that privilege for this MR
|
|
One of the things we do during the tests is change the config. But that's global state and different tests were interfering.
E.g. one test would set `clear_config([:instance, :admin_privileges], [:statuses_read])`, but while that runs, another test may
do `clear_config([:instance, :admin_privileges], [:user_invite])`. Now the code for the first test checks the setting, and it
finds `:user_invite` instead of `:statuses_read`.
Now the modules where this happens are marked to run synchronously, so they don't interfere with each other.
|
|
|
|
|
|
|
|
|
|
|
|
Everything that was done through this setting, can now be set by giving the proper privileges to the roles.
|
|
This was the last in :require_privileged_staff. I'll remove that in the next commit
|
|
I only moved the ones from the :require_privileged_staff block for now
|
|
|
|
|
|
hackney adapter helper: enable TLSv1.3
See merge request pleroma/pleroma!3661
|
|
|
|
|
|
The list of TLS versions was added by
8bd2b6eb138ace3408a03c78ecc339fc35b19f10 when hackney version was
pinned to 1.15.2. Later hackney version was upgraded
(166455c88441b22455d996ed528ed4804514a3c0) but the list of TLS
versions wasn't removed. From the hackney point of view, this list has
been replaced by the OTP defaults since 0.16.0
(734694ea4e24f267864c459a2f050e943adc6694).
It looks like the same issue already occurred before:
0cb7b0ea8477bdd7af2e5e9071843be5b8623dff.
A way to test this issue (where example.com is an ActivityPub site
which uses TLSv1.3 only):
$ PLEROMA_CONFIG_PATH=/path/to/config.exs pleroma start_iex
Erlang/OTP 22 [erts-10.7.2.16] [source] [64-bit] [smp:2:2] [ds:2:2:10] [async-threads:1] [hipe]
Erlang/OTP 22 [erts-10.7.2.16] [source] [64-bit] [smp:2:2] [ds:2:2:10] [async-threads:1] [hipe]
Interactive Elixir (1.10.4) - press Ctrl+C to exit (type h() ENTER for help)
iex(pleroma@127.0.0.1)2> Pleroma.Object.Fetcher.fetch_and_contain_remote_object_from_id("https://example.com/@/Nick/")
{:error,
{:tls_alert,
{:protocol_version,
'TLS client: In state hello received SERVER ALERT: Fatal - Protocol Version\n'}}}
With this patch, the output is the expected one:
iex(pleroma@127.0.0.1)3> Pleroma.Object.Fetcher.fetch_and_contain_remote_object_from_id("https://example.com/@/Nick/")
{:error,
{:ok,
%{
"@context" => [
"https://www.w3.org/ns/activitystreams",
"https://w3id.org/security/v1",
%{
"Emoji" => "toot:Emoji",
"Hashtag" => "as:Hashtag",
"atomUri" => "ostatus:atomUri",
"conversation" => "ostatus:conversation",
"featured" => "toot:featured",
"focalPoint" => %{"@container" => "@list", "@id" => "toot:focalPoint"},
"inReplyToAtomUri" => "ostatus:inReplyToAtomUri",
"manuallyApprovesFollowers" => "as:manuallyApprovesFollowers",
"movedTo" => "as:movedTo",
"ostatus" => "http://ostatus.org#",
"sensitive" => "as:sensitive",
"toot" => "http://joinmastodon.org/ns#"
}
],
"endpoints" => %{"sharedInbox" => "https://example.com/inbox"},
"followers" => "https://example.com/@/Nick/followers",
"following" => nil,
"icon" => %{
"type" => "Image",
"url" => "https://example.com/static/media/[...].png"
},
"id" => "https://example.com/@/Nick/",
"inbox" => "https://example.com/@/Nick/inbox",
"liked" => nil,
"name" => "Nick",
"outbox" => "https://example.com/@/Nick/outbox",
"preferredUsername" => "Nick",
"publicKey" => %{
"id" => "https://example.com/@/Nick/#main-key",
"owner" => "https://example.com/@/Nick/",
"publicKeyPem" => "[...]
},
"summary" => "",
"type" => "Person",
"url" => "https://example.com/@/Nick/"
}}
A way to test the reverse proxy bits of this issue (where example.com allows TLSv1.3 only):
iex(pleroma@127.0.0.1)1> Pleroma.ReverseProxy.Client.Hackney.request("GET", "https://example.com", [], [])
{:error,
{:tls_alert,
{:protocol_version,
'TLS client: In state hello received SERVER ALERT: Fatal - Protocol Version\n'}}}
|
|
Instruct users to run 'git pull' as the pleroma user
See merge request pleroma/pleroma!3667
|
|
StealEmojiPolicy: fix String rejected_shortcodes
See merge request pleroma/pleroma!3673
|
|
* rejected_shortcodes is defined as a list of strings in the
configuration description. As such, database-based configuration was
led to handle those settings as strings, and not as the actually
expected type, Regex.
* This caused each message passing through this MRF, if a rejected
shortcode was set and the emoji did not exist already on the instance,
to fail federating, as an exception was raised, swiftly caught and
mostly silenced.
* This commit fixes the issue by introducing new behavior: strings are
now handled as perfect matches for an emoji shortcode (meaning that if
the emoji-to-be-pulled's shortcode is in the blacklist, it will be
rejected), while still supporting Regex types as before.
|
|
|
|
Also use actor_type to determine if an account is a bot in antiFollowbotPolicy
Closes #2561
See merge request pleroma/pleroma!3498
|
|
|
|
squash
|
|
Merge back 2.4.3
See merge request pleroma/pleroma!3663
|
|
|
|
Ref: fix-local-public
|
|
Ref: fix-local-public
|
|
|
|
Fix incorrect fallback when English is set to first language
See merge request pleroma/pleroma!3656
|
|
|
|
|
|
Fix eratic test for POST /api/pleroma/admin/reports/:id/notes
See merge request pleroma/pleroma!3653
|
|
It retrieved two ReportNotes and then checked one of them. But the order isn't guaranteed, while the test tested on the content of the first ReportNote.
I made the test on the content more generic
|
|
|
|
Signed-off-by: marcin mikołajczak <git@mkljczk.pl>
|
|
Translate backend-rendered pages
See merge request pleroma/pleroma!3634
|
|
Update Caddyfile to Caddy v2
Closes #2764
See merge request pleroma/pleroma!3641
|
|
Delete report notifs when demoting from superuser
Closes #2840
See merge request pleroma/pleroma!3642
|
|
|
