warning: a struct for Pleroma.Web.CommonAPI.ActivityDraft is expected on struct update:
%Pleroma.Web.CommonAPI.ActivityDraft{draft | object: object}
but got type:
dynamic()
where "draft" was given the type:
# type: dynamic()
# from: lib/pleroma/web/common_api/activity_draft.ex:91:22
draft
when defining the variable "draft", you must also pattern match on "%Pleroma.Web.CommonAPI.ActivityDraft{}".
hint: given pattern matching is enough to catch typing errors, you may optionally convert the struct update into a map update. For example, instead of:
user = some_function()
%User{user | name: "John Doe"}
it is enough to write:
%User{} = user = some_function()
%{user | name: "John Doe"}
typing violation found at:
│
102 │ %__MODULE__{draft | object: object}
│ ~
│
└─ lib/pleroma/web/common_api/activity_draft.ex:102:5: Pleroma.Web.CommonAPI.ActivityDraft.listen_object/1
Status visibility checks for post interactions, stop leaking internal Activity representation (Akkoma PR 1014 and 1018)
Closes#3383
See merge request pleroma/pleroma!4400
Akkoma patches returned 403 and some of my previous commits returned 422.
This unifies the errors returned to 404 "Record not found", gaslighting
user just like we do for other endpoints and how Mastodon does it.
Port of Akkoma PR 1014 with a few changes:
- comments regarding akkomafe changed to Pleroma-FE when applicable
- different error message for replying to/interacting with invisible post
in Pleroma.Web.CommonAPI.ActivityDraft.in_reply_to/1
- split "doesn't do funny things to other users favs" test into three:
- can't unfavourite post that isn't favourited
- can't unfavourite other user's favs
- can't unfavourite other user's favs using their activity
- switched order of args for some CommonAPI function since Akkoma hasn't
backported our old change for that
Pleroma.Web.CommonAPI.ActivityDraft.in_reply_to/1 now refactored to use
`with` statement as in Akkoma. Some defp in_reply_to/1 were therefore removed
Original PR author: Oneric
Original commit message:
It doesn't make sense to like, react, reply, etc to something you cannot
see and is unexpected for the author of the interacted with post and
might make them believe the reacting user actually _can_ see the post.
Wrt to fav, reblog, reaction indexes the missing visibility check was
also leaking some (presumably/hopefully) low-severity data.
Add full-API test for all modes of interactions with private posts.
Sometimes people put emoji in the subject, which results in the subject
looking broken if someone replies to it from a server that does not
have the said emoji under the same shortcode. This patch solves the problem
by extending the emoji set available in the summary to that of the parent
post.
