pleroma issueshttps://git.pleroma.social/pleroma/pleroma/-/issues2020-07-08T03:25:35Zhttps://git.pleroma.social/pleroma/pleroma/-/issues/1918Better support for resetting avatar/header/background2020-07-08T03:25:35ZShpuld ShpludsonBetter support for resetting avatar/header/backgroundCurrently you can't remove/reset the profile images through update_credentials, but instead there's new custom pleroma api endpoints (`/api/v1/pleroma/accounts/update_avatar` etc) for resetting each individual images. however that api is...Currently you can't remove/reset the profile images through update_credentials, but instead there's new custom pleroma api endpoints (`/api/v1/pleroma/accounts/update_avatar` etc) for resetting each individual images. however that api is pretty ugly and poorly documented. for whatever reason those endpoints don't return useful data (would expect an account), and their parameters seem pretty wild (avatar takes 'img', banner takes 'banner' and background takes 'img' again). I wouldn't want to make use of that api as once it's in use it'll be harder to rip out or fix.
I talked with lain about it and figured maybe it'd be a better idea to allow giving empty strings in the forms to mastoapi PATCH update_credentials for avatar/header etc and have it reset the image that way. currently we return 200 OK but don't do anything if you give null in json for avatar/header/background, and error when you try giving null to the form (which is always supposed to be used for files according to masto docs) but empty string in forms 200 OK with no effect again. there was some concern that null in json might be sent by some applications expecting it not to have side effects, so maybe empty string is safer in that regard.
more discussion on the FE MR about this stuff: https://git.pleroma.social/pleroma/pleroma-fe/-/merge_requests/1156https://git.pleroma.social/pleroma/pleroma/-/issues/1031Add `pleroma.parent_visible` to the status view2020-06-29T08:39:53Zrinpatchrin+pleroma@patch.cxAdd `pleroma.parent_visible` to the status viewAs discussed on irc, this will be useful for the frontend to hide/cross out/gray out the "Reply To" popup when the parent post is inaccessible. Since we already need to get the parent post to render the view there won't be a performance ...As discussed on irc, this will be useful for the frontend to hide/cross out/gray out the "Reply To" popup when the parent post is inaccessible. Since we already need to get the parent post to render the view there won't be a performance hit, I think
cc @hj @shpuld lainlainhttps://git.pleroma.social/pleroma/pleroma/-/issues/1789Status 'text' property is inconsistent in mastoapi2020-05-19T14:03:53ZShpuld ShpludsonStatus 'text' property is inconsistent in mastoapiA status has a 'text' property for plaintext, pleroma returns it all the time in regular statuses, mastodon's api doc says it's used only for delete&redraft. For some reason, in status.reblog we don't have a 'text' property at all, which...A status has a 'text' property for plaintext, pleroma returns it all the time in regular statuses, mastodon's api doc says it's used only for delete&redraft. For some reason, in status.reblog we don't have a 'text' property at all, which it makes it hard to actually rely on this property so it's kinda useless and misleading if anything. If clients are meant to use the property, it should be in reblogs too.https://git.pleroma.social/pleroma/pleroma/-/issues/1081Extend timeline APIs to filter out replies2020-04-24T16:32:15ZfeldExtend timeline APIs to filter out repliesRight now if you enable the status filtering in the FE it's done 100% in the FE.
![image](/uploads/d4492d8fc8b2b2beabbdb545ec3e45f9/image.png)
This means when I scroll to the bottom of my feed the refresh can pull less than 20 statuse...Right now if you enable the status filtering in the FE it's done 100% in the FE.
![image](/uploads/d4492d8fc8b2b2beabbdb545ec3e45f9/image.png)
This means when I scroll to the bottom of my feed the refresh can pull less than 20 statuses to read because a large number of the statuses in the next batch were replies. A good UX would have the backend actually provide 20 parent statuses.Alexander StrizhakovAlexander Strizhakovhttps://git.pleroma.social/pleroma/pleroma/-/issues/84Add better error handling (action_fallback)2020-04-22T14:12:39ZlainAdd better error handling (action_fallback)For now, many endpoints will simply return a 500 when they fail. They should return an error. The easiest way to do this would be action_fallback, I think.
http://phoenixframework.org/blog/phoenix-1-3-0-releasedFor now, many endpoints will simply return a 500 when they fail. They should return an error. The easiest way to do this would be action_fallback, I think.
http://phoenixframework.org/blog/phoenix-1-3-0-releasedhttps://git.pleroma.social/pleroma/pleroma/-/issues/138Incorrect behaviour for Link header2020-04-22T13:56:58ZMorgan Bazalgettethe@howl.moeIncorrect behaviour for Link headerWhen a user has no more statuses, on `/api/v1/accounts/:id/statuses` no `Link` header is given. Mastodon, instead, gives only a `link: <https://mstdn.io/api/v1/accounts/96921/statuses?exclude_replies=false&since_id=99740919846633556>; re...When a user has no more statuses, on `/api/v1/accounts/:id/statuses` no `Link` header is given. Mastodon, instead, gives only a `link: <https://mstdn.io/api/v1/accounts/96921/statuses?exclude_replies=false&since_id=99740919846633556>; rel="prev"` header, where since_id is the ID of the first post returned. I'd take the guess that this is what causes pleroma/mastofe#9 to happen.minibikiniminibikinihttps://git.pleroma.social/pleroma/pleroma/-/issues/1072Support muting/unmuting notifications2019-07-14T13:29:35Zrinpatchrin+pleroma@patch.cxSupport muting/unmuting notificationsCurrently we have `muting_notifications` hardcoded to false. https://docs.joinmastodon.org/api/rest/mutes/#post-api-v1-accounts-id-muteCurrently we have `muting_notifications` hardcoded to false. https://docs.joinmastodon.org/api/rest/mutes/#post-api-v1-accounts-id-muteAlexander StrizhakovAlexander Strizhakovhttps://git.pleroma.social/pleroma/pleroma/-/issues/967/api/v1/conversations pagination is different from Mastodon2019-06-10T03:09:30ZEugenij/api/v1/conversations pagination is different from MastodonMastodon's `GET /api/v1/conversations`:
- link headers [contain `last_status` ids](https://github.com/tootsuite/mastodon/blob/8e7fc7ec73c0743df378403ad2e704c9fae70400/app/controllers/api/v1/conversations_controller.rb#L44-L62) instead o...Mastodon's `GET /api/v1/conversations`:
- link headers [contain `last_status` ids](https://github.com/tootsuite/mastodon/blob/8e7fc7ec73c0743df378403ad2e704c9fae70400/app/controllers/api/v1/conversations_controller.rb#L44-L62) instead of conversation ids
- `min_id`, `max_id`, and `since_id` [use `last_status` ids](https://github.com/tootsuite/mastodon/blob/8e7fc7ec73c0743df378403ad2e704c9fae70400/app/models/account_conversation.rb#L39-L58) instead of conversation idshttps://git.pleroma.social/pleroma/pleroma/-/issues/716Preserve parameters in link headers2019-03-07T09:33:54ZlainPreserve parameters in link headersOptions like `media_only` won't be preserved in the link header, but they should be.Options like `media_only` won't be preserved in the link header, but they should be.https://git.pleroma.social/pleroma/pleroma/-/issues/83Missing reports API2019-02-22T20:35:50ZfeldMissing reports APIWe don't have a way to deal with it yet, but this looks like low hanging fruit to implement.
/api/v1/reports
https://github.com/tootsuite/documentation/blob/master/Using-the-API/API.md#reportsWe don't have a way to deal with it yet, but this looks like low hanging fruit to implement.
/api/v1/reports
https://github.com/tootsuite/documentation/blob/master/Using-the-API/API.md#reportshttps://git.pleroma.social/pleroma/pleroma/-/issues/116Send `delete` event type on Streaming API2019-01-20T23:06:23ZMorgan Bazalgettethe@howl.moeSend `delete` event type on Streaming APIOn Mastodon, in order for deleted posts to disappear from the timeline once, the streaming API sends to the user an event `delete` with the ID of the deleted status:
```json
{ ...On Mastodon, in order for deleted posts to disappear from the timeline once, the streaming API sends to the user an event `delete` with the ID of the deleted status:
```json
{
"event": "delete",
"payload": "4348674"
}
```
I think Pleroma should send this as well, so deleted posts get actually deleted on the timeline.https://git.pleroma.social/pleroma/pleroma/-/issues/90Mustor app (iOS) cannot login2019-01-20T13:01:28ZfeldMustor app (iOS) cannot loginApp asks you to input your Instance Domain to begin oauth. It immediately errors. Pleroma log is as follows:
`
Dec 6 22:11:57 social pleroma: [info] POST /api/v1/apps
Dec 6 22:11:57 social pleroma: #Ecto.Changeset<action: nil,
Dec 6 ...App asks you to input your Instance Domain to begin oauth. It immediately errors. Pleroma log is as follows:
`
Dec 6 22:11:57 social pleroma: [info] POST /api/v1/apps
Dec 6 22:11:57 social pleroma: #Ecto.Changeset<action: nil,
Dec 6 22:11:57 social pleroma: changes: %{client_id: "cCUbutxwjCdhZQcObw41_0kuYanYOqI0FY2A6JOnwH0=",
Dec 6 22:11:57 social pleroma: client_name: "Mastodon-iOS",
Dec 6 22:11:57 social pleroma: client_secret: "r36i6E3L8LBDdjnRk3pS8ti2Ir6wFk2272qxjH3Gl1s=",
Dec 6 22:11:57 social pleroma: redirect_uris: "mastodondarkcl://oauth", scopes: "read write follow",
Dec 6 22:11:57 social pleroma: website: "https://github.com/darkcl"}, errors: [],
Dec 6 22:11:57 social pleroma: data: #Pleroma.Web.OAuth.App<>, valid?: true>
Dec 6 22:11:57 social pleroma: {:ok,
Dec 6 22:11:57 social pleroma: %Pleroma.Web.OAuth.App{__meta__: #Ecto.Schema.Metadata<:loaded, "apps">,
Dec 6 22:11:57 social pleroma: client_id: "cCUbutxwjCdhZQcObw41_0kuYanYOqI0FY2A6JOnwH0=",
Dec 6 22:11:57 social pleroma: client_name: "Mastodon-iOS",
Dec 6 22:11:57 social pleroma: client_secret: "r36i6E3L8LBDdjnRk3pS8ti2Ir6wFk2272qxjH3Gl1s=", id: 23,
Dec 6 22:11:57 social pleroma: inserted_at: ~N[2017-12-06 22:11:57.736756],
Dec 6 22:11:57 social pleroma: redirect_uris: "mastodondarkcl://oauth", scopes: "read write follow",
Dec 6 22:11:57 social pleroma: updated_at: ~N[2017-12-06 22:11:57.736778],
Dec 6 22:11:57 social pleroma: website: "https://github.com/darkcl"}}
`https://git.pleroma.social/pleroma/pleroma/-/issues/148Direct Message API2018-05-29T11:50:21ZMorgan Bazalgettethe@howl.moeDirect Message APINext mastodon version will come with direct messages, and with it new APIs...
This is the relevant pull request: https://github.com/tootsuite/mastodon/pull/4514
Checklist:
- [ ] Streaming API for 'direct'
- [ ] `/api/v1/timelines/dire...Next mastodon version will come with direct messages, and with it new APIs...
This is the relevant pull request: https://github.com/tootsuite/mastodon/pull/4514
Checklist:
- [ ] Streaming API for 'direct'
- [ ] `/api/v1/timelines/direct`
I've removed references to the direct messages column from mastofe as a temporary countermeasure, but I expect mastodon clients to start depending on this API soon enoughhttps://git.pleroma.social/pleroma/pleroma/-/issues/69Add Unrepeats2018-05-13T09:32:33ZlainAdd UnrepeatsLike unlikes, only for repeats.Like unlikes, only for repeats.1.0https://git.pleroma.social/pleroma/pleroma/-/issues/124MastoAPI: Support `pinned` parameter in Account api2018-04-21T16:25:20ZlainMastoAPI: Support `pinned` parameter in Account apiThis is part of https://git.pleroma.social/pleroma/pleroma/issues/109 but gets its own issue because it is a real bug.
When you use the pinned=true parameter, Mastodon versions > 1.6 will return only the pinned posts. As we don't suppor...This is part of https://git.pleroma.social/pleroma/pleroma/issues/109 but gets its own issue because it is a real bug.
When you use the pinned=true parameter, Mastodon versions > 1.6 will return only the pinned posts. As we don't support this yet, we'll return all posts, so the client will think all posts are pinned. We claim to support 2.3.3, so this is a bug.
The easiest quick fix is to just return and empty list when there parameter is there and worry about actually supporting it later.
https://github.com/tootsuite/documentation/blob/master/Using-the-API/API.md#getting-an-accounts-statuses1.0https://git.pleroma.social/pleroma/pleroma/-/issues/113MastoAPI: /api/web/settings endpoint2018-04-21T16:25:20ZMorgan Bazalgettethe@howl.moeMastoAPI: /api/web/settings endpointIdeally should only serve the purpose of storing the data and giving it back on the initial-state when a user loads /web. See: https://git.pleroma.social/tyge/mastofe/issues/6#note_1442Ideally should only serve the purpose of storing the data and giving it back on the initial-state when a user loads /web. See: https://git.pleroma.social/tyge/mastofe/issues/6#note_14421.0https://git.pleroma.social/pleroma/pleroma/-/issues/91Tootle app (iOS) cannot login2018-03-10T13:17:45ZfeldTootle app (iOS) cannot loginFails to pull up the oauth page like it does for mastodon.social
`Dec 6 22:24:06 social pleroma: [info] POST /api/v1/apps
Dec 6 22:24:06 social pleroma: #Ecto.Changeset<action: nil,
Dec 6 22:24:06 social pleroma: changes: %{client_i...Fails to pull up the oauth page like it does for mastodon.social
`Dec 6 22:24:06 social pleroma: [info] POST /api/v1/apps
Dec 6 22:24:06 social pleroma: #Ecto.Changeset<action: nil,
Dec 6 22:24:06 social pleroma: changes: %{client_id: "aDY0KgqOopa0v-W5mFN0RMP-rpMVuHbSLYAFetUHJdc=",
Dec 6 22:24:06 social pleroma: client_name: "Tootle for Mastodon",
Dec 6 22:24:06 social pleroma: client_secret: "E26qk-rcnTlMdZH89liB93cKOzxH7yTYwIGdOmOccjE=",
Dec 6 22:24:06 social pleroma: redirect_uris: "jp-morilab-mastodonapp://authorize",
Dec 6 22:24:06 social pleroma: scopes: "read write follow"}, errors: [], data: #Pleroma.Web.OAuth.App<>,
Dec 6 22:24:06 social pleroma: valid?: true>
Dec 6 22:24:06 social pleroma: {:ok,
Dec 6 22:24:06 social pleroma: %Pleroma.Web.OAuth.App{__meta__: #Ecto.Schema.Metadata<:loaded, "apps">,
Dec 6 22:24:06 social pleroma: client_id: "aDY0KgqOopa0v-W5mFN0RMP-rpMVuHbSLYAFetUHJdc=",
Dec 6 22:24:06 social pleroma: client_name: "Tootle for Mastodon",
Dec 6 22:24:06 social pleroma: client_secret: "E26qk-rcnTlMdZH89liB93cKOzxH7yTYwIGdOmOccjE=", id: 27,
Dec 6 22:24:06 social pleroma: inserted_at: ~N[2017-12-06 22:24:06.912025],
Dec 6 22:24:06 social pleroma: redirect_uris: "jp-morilab-mastodonapp://authorize",
Dec 6 22:24:06 social pleroma: scopes: "read write follow", updated_at: ~N[2017-12-06 22:24:06.912038],
Dec 6 22:24:06 social pleroma: website: nil}}
Dec 6 22:24:06 social pleroma: [info] Sent 200 in 3ms`https://git.pleroma.social/pleroma/pleroma/-/issues/72Add missing next/previous headers in mastodon api2018-03-09T15:06:09ZlainAdd missing next/previous headers in mastodon apiThe timelines have next/prev headers with links to get more statuses. We only have them for a few routes right now.The timelines have next/prev headers with links to get more statuses. We only have them for a few routes right now.https://git.pleroma.social/pleroma/pleroma/-/issues/86Failed login on Masto UI returns "expected action/2 to return a plug.conn"2017-12-05T11:38:51ZHyper! (Stitch)Failed login on Masto UI returns "expected action/2 to return a plug.conn"See image.
![Capture](/uploads/1e4ed38acce763a62f043e55769dd1fa/Capture.PNG)See image.
![Capture](/uploads/1e4ed38acce763a62f043e55769dd1fa/Capture.PNG)https://git.pleroma.social/pleroma/pleroma/-/issues/78Support Mastodon-Style sensitive content bit2017-11-18T14:34:41ZlainSupport Mastodon-Style sensitive content bitIt's just an invisible #nsfw tag, add it in the post api.It's just an invisible #nsfw tag, add it in the post api.