pleroma merge requestshttps://git.pleroma.social/pleroma/pleroma/-/merge_requests2024-03-20T13:26:49Zhttps://git.pleroma.social/pleroma/pleroma/-/merge_requests/4096Fix BookmarkFolderView, add test2024-03-20T13:26:49Zmarcin mikołajczakFix BookmarkFolderView, add testhttps://git.pleroma.social/pleroma/pleroma/-/merge_requests/4081Add some missing fields to instanceV22024-03-19T14:54:53Zmarcin mikołajczakAdd some missing fields to instanceV2https://git.pleroma.social/pleroma/pleroma/-/merge_requests/4090Set defaults values on transient objects (attachment, poll options) validators2024-03-19T12:44:19ZHaelwennSet defaults values on transient objects (attachment, poll options) validators### Checklist
- [x] Adding a changelog: In the `changelog.d` directory, create a file named `<code>.<type>`.### Checklist
- [x] Adding a changelog: In the `changelog.d` directory, create a file named `<code>.<type>`.https://git.pleroma.social/pleroma/pleroma/-/merge_requests/4095CI: Move changelog check to later in the pipeline2024-03-19T12:02:16ZlainCI: Move changelog check to later in the pipeline### Checklist
- [ ] Adding a changelog: In the `changelog.d` directory, create a file named `<code>.<type>`.
`<code>` can be anything, but we recommend using a more or less unique identifier to avoid collisions, such as the branch nam...### Checklist
- [ ] Adding a changelog: In the `changelog.d` directory, create a file named `<code>.<type>`.
`<code>` can be anything, but we recommend using a more or less unique identifier to avoid collisions, such as the branch name.
`<type>` can be `add`, `change`, `remove`, `fix`, `security` or `skip`. `skip` is only used if there is no user-visible change in the MR (for example, only editing comments in the code). Otherwise, choose a type that corresponds to your change.
In the file, write the changelog entry. For example, if an MR adds group functionality, we can create a file named `group.add` and write `Add group functionality` in it.
If one changelog entry is not enough, you may add more. But that might mean you can split it into two MRs. Only use more than one changelog entry if you really need to (for example, when one change in the code fix two different bugs, or when refactoring).https://git.pleroma.social/pleroma/pleroma/-/merge_requests/4094Tests: Explicitly set db pool size and max cases to the same value.2024-03-19T07:44:13ZlainTests: Explicitly set db pool size and max cases to the same value.### Checklist
- [ ] Adding a changelog: In the `changelog.d` directory, create a file named `<code>.<type>`.
`<code>` can be anything, but we recommend using a more or less unique identifier to avoid collisions, such as the branch nam...### Checklist
- [ ] Adding a changelog: In the `changelog.d` directory, create a file named `<code>.<type>`.
`<code>` can be anything, but we recommend using a more or less unique identifier to avoid collisions, such as the branch name.
`<type>` can be `add`, `change`, `remove`, `fix`, `security` or `skip`. `skip` is only used if there is no user-visible change in the MR (for example, only editing comments in the code). Otherwise, choose a type that corresponds to your change.
In the file, write the changelog entry. For example, if an MR adds group functionality, we can create a file named `group.add` and write `Add group functionality` in it.
If one changelog entry is not enough, you may add more. But that might mean you can split it into two MRs. Only use more than one changelog entry if you really need to (for example, when one change in the code fix two different bugs, or when refactoring).https://git.pleroma.social/pleroma/pleroma/-/merge_requests/4093Update minimum Postgres version to 11.0; disable JIT2024-03-19T04:46:45ZfeldUpdate minimum Postgres version to 11.0; disable JIThttps://git.pleroma.social/pleroma/pleroma/-/merge_requests/4092CI: Remove RUM tests.2024-03-18T21:24:54ZlainCI: Remove RUM tests.This removes the very unstable RUM tests. It fails all the time and ruins our CI.
I want to deprecate and remove RUM support. Search can be added either via meilisearch or other similar pluggable searches. AFAICT, barely anyone even use...This removes the very unstable RUM tests. It fails all the time and ruins our CI.
I want to deprecate and remove RUM support. Search can be added either via meilisearch or other similar pluggable searches. AFAICT, barely anyone even uses it these days.https://git.pleroma.social/pleroma/pleroma/-/merge_requests/4080Bookmark folders2024-03-18T14:26:26Zmarcin mikołajczakBookmark folders### Checklist
- [x] Adding a changelog: In the `changelog.d` directory, create a file named `<code>.<type>`.
`<code>` can be anything, but we recommend using a more or less unique identifier to avoid collisions, such as the branch nam...### Checklist
- [x] Adding a changelog: In the `changelog.d` directory, create a file named `<code>.<type>`.
`<code>` can be anything, but we recommend using a more or less unique identifier to avoid collisions, such as the branch name.
`<type>` can be `add`, `change`, `remove`, `fix`, `security` or `skip`. `skip` is only used if there is no user-visible change in the MR (for example, only editing comments in the code). Otherwise, choose a type that corresponds to your change.
In the file, write the changelog entry. For example, if an MR adds group functionality, we can create a file named `group.add` and write `Add group functionality` in it.
If one changelog entry is not enough, you may add more. But that might mean you can split it into two MRs. Only use more than one changelog entry if you really need to (for example, when one change in the code fix two different bugs, or when refactoring).https://git.pleroma.social/pleroma/pleroma/-/merge_requests/3962Expose nonAnonymous field from Smithereen polls2024-03-18T06:26:29Zmarcin mikołajczakExpose nonAnonymous field from Smithereen pollsSmithereen allows users to specify, whether the results of their polls are public (who voted for each option) or anonymous. The results are federated.
As Pleroma users might except that the results are only visible to the instance admin...Smithereen allows users to specify, whether the results of their polls are public (who voted for each option) or anonymous. The results are federated.
As Pleroma users might except that the results are only visible to the instance admin, it might sense to put some information to clarify the poll results are actually public.
![obraz](/uploads/cadc3ca1de17b20b6f12b008ae78daa5/obraz.png)https://git.pleroma.social/pleroma/pleroma/-/merge_requests/4089Notifications: filter on users rather than activities2024-03-18T04:53:43ZMatthieu RakotojaonaNotifications: filter on users rather than activitiesThe issue in #3218 is that the query looks at blocked domains in the entities to potentially return. Since there is no column or index for the domain but only the full `ap_id`, pg has to sequentially scan the full table, extract the doma...The issue in #3218 is that the query looks at blocked domains in the entities to potentially return. Since there is no column or index for the domain but only the full `ap_id`, pg has to sequentially scan the full table, extract the domain, and check.
One solution could have been to create that index with the extracted domain, but that's one more index to manage.
The solution in this MR is to do the scan not on the activities table (which will always be the biggest one) but on the users table, since it's expected to have far fewer entries. Here's the `EXPLAIN ANALYZE`:
```SQL
EXPLAIN ANALYSE SELECT
n0."id",
n0."seen",
n0."type",
n0."user_id",
n0."activity_id",
n0."inserted_at",
n0."updated_at",
a1."id",
a1."data",
a1."local",
a1."actor",
a1."recipients",
a1."inserted_at",
a1."updated_at",
o2."id",
o2."data",
o2."inserted_at",
o2."updated_at"
FROM "notifications" AS n0
INNER JOIN "activities" AS a1 ON a1."id" = n0."activity_id"
LEFT OUTER JOIN "objects" AS o2 ON (o2."data"->>'id') = associated_object_id(a1."data")
INNER JOIN "users" AS u3 ON u3."ap_id" = a1."actor"
LEFT OUTER JOIN "thread_mutes" AS t4 ON (t4."user_id" = '0000017d-2fdc-ab78-4e1d-d01859de0000') AND (t4."context" = a1."data"->>'context')
WHERE (n0."user_id" = '0000017d-2fdc-ab78-4e1d-d01859de0000')
AND (u3."is_active")
AND (NOT (u3."ap_id" = ANY(ARRAY[]::text[])))
AND (t4."user_id" IS NULL)
AND (NOT (u3."ap_id" = ANY(ARRAY[/* ELIDED FOR PRIVACY */])))
AND (NOT (substring(u3."ap_id" from '.*://([^/]*)') = ANY(ARRAY[]::text[]))
OR u3."ap_id" = ANY(
SELECT ap_id FROM users AS u
INNER JOIN following_relationships AS fr
ON u.id = fr.following_id
WHERE fr.follower_id = '0000017d-2fdc-ab78-4e1d-d01859de0000'
AND fr.state = 2)
)
ORDER BY n0."id" desc nulls last
LIMIT 20
;
QUERY PLAN
-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Limit (cost=89147.53..89147.58 rows=20 width=2039) (actual time=285.930..285.938 rows=20 loops=1)
-> Sort (cost=89147.53..89149.50 rows=788 width=2039) (actual time=285.929..285.934 rows=20 loops=1)
Sort Key: n0.id DESC NULLS LAST
Sort Method: top-N heapsort Memory: 162kB
-> Nested Loop Anti Join (cost=63297.66..89126.56 rows=788 width=2039) (actual time=232.389..283.957 rows=3323 loops=1)
Join Filter: ((t4.context)::text = (a1.data ->> 'context'::text))
-> Nested Loop Left Join (cost=63297.51..89104.60 rows=788 width=2039) (actual time=232.370..282.576 rows=3323 loops=1)
-> Hash Join (cost=63296.71..88076.90 rows=788 width=756) (actual time=231.866..253.443 rows=3323 loops=1)
Hash Cond: ((a1.actor)::text = (u3.ap_id)::text)
-> Nested Loop (cost=0.43..24771.88 rows=3330 width=756) (actual time=0.042..19.411 rows=3330 loops=1)
-> Seq Scan on notifications n0 (cost=0.00..86.03 rows=3330 width=61) (actual time=0.021..0.875 rows=3330 loops=1)
Filter: (user_id = '0000017d-2fdc-ab78-4e1d-d01859de0000'::uuid)
Rows Removed by Filter: 112
-> Index Scan using activities_pkey on activities a1 (cost=0.43..7.41 rows=1 width=695) (actual time=0.005..0.005 rows=1 loops=3330)
Index Cond: (id = n0.activity_id)
-> Hash (cost=62356.72..62356.72 rows=75165 width=38) (actual time=231.378..231.379 rows=75641 loops=1)
Buckets: 131072 Batches: 1 Memory Usage: 6155kB
-> Bitmap Heap Scan on users u3 (cost=3414.06..62356.72 rows=75165 width=38) (actual time=15.891..202.407 rows=75641 loops=1)
Recheck Cond: is_active
Filter: ((ap_id)::text <> ALL ('{/* ELIDED FOR PRIVACY */}'::text[]))
Rows Removed by Filter: 2
Heap Blocks: exact=41161
-> Bitmap Index Scan on users_is_active_index (cost=0.00..824.17 rows=75167 width=0) (actual time=8.913..8.914 rows=75650 loops=1)
Index Cond: (is_active = true)
-> Index Scan using objects_unique_apid_index on objects o2 (cost=0.80..1.30 rows=1 width=1283) (actual time=0.005..0.005 rows=1 loops=3323)
Index Cond: ((data ->> 'id'::text) = (associated_object_id(a1.data))::text)
-> Materialize (cost=0.14..8.17 rows=1 width=516) (actual time=0.000..0.000 rows=0 loops=3323)
-> Index Only Scan using unique_index on thread_mutes t4 (cost=0.14..8.16 rows=1 width=516) (actual time=0.012..0.012 rows=0 loops=1)
Index Cond: (user_id = '0000017d-2fdc-ab78-4e1d-d01859de0000'::uuid)
Heap Fetches: 0
Planning Time: 4.547 ms
Execution Time: 286.993 ms
(32 lignes)
```
On my dev machine this query goes from ~5s to ~300ms
This is a partial fix for #3218 : it works under the assumption that `num(activities)/num(users)`. This assumption is not verified when there's a lot of spam, because then new accounts are created and the ratio goes up. The proper fix is to delete notifications of blocked/muted users and domains and fetch all the rest, but that's destructive so I didn't want to do that for my very first MR
### Checklist
- [x] Adding a changelog: In the `changelog.d` directory, create a file named `<code>.<type>`.https://git.pleroma.social/pleroma/pleroma/-/merge_requests/4083Consider a case when users.inbox is nil (Fix 3241)2024-03-17T13:39:05ZKaede FujisakiConsider a case when users.inbox is nil (Fix 3241)Fix ["Followers only" does not send a note to other instances. (#3241)](https://git.pleroma.social/pleroma/pleroma/-/issues/3241)
Closes #3241
users.inbox can be nil:
```
pleroma=# \d users
...Fix ["Followers only" does not send a note to other instances. (#3241)](https://git.pleroma.social/pleroma/pleroma/-/issues/3241)
Closes #3241
users.inbox can be nil:
```
pleroma=# \d users
Table "public.users"
Column | Type | Collation | Nullable | Default
--------------------------------------+--------------------------------+-----------+----------+-------------------------------------------------------------------------------------------
...
inbox | text | | |
```
But currently, it is not handled. In this MR, handle cases when inbox is nil.
### Checklist
- [X] Adding a changelog: In the `changelog.d` directory, create a file named `<code>.<type>`.
`<code>` can be anything, but we recommend using a more or less unique identifier to avoid collisions, such as the branch name.
`<type>` can be `add`, `change`, `remove`, `fix`, `security` or `skip`. `skip` is only used if there is no user-visible change in the MR (for example, only editing comments in the code). Otherwise, choose a type that corresponds to your change.
In the file, write the changelog entry. For example, if an MR adds group functionality, we can create a file named `group.add` and write `Add group functionality` in it.
If one changelog entry is not enough, you may add more. But that might mean you can split it into two MRs. Only use more than one changelog entry if you really need to (for example, when one change in the code fix two different bugs, or when refactoring).https://git.pleroma.social/pleroma/pleroma/-/merge_requests/4082Add ForceMention mrf2024-03-17T12:32:20Zmarcin mikołajczakAdd ForceMention mrf### Checklist
- [x] Adding a changelog: In the `changelog.d` directory, create a file named `<code>.<type>`.
`<code>` can be anything, but we recommend using a more or less unique identifier to avoid collisions, such as the branch na...### Checklist
- [x] Adding a changelog: In the `changelog.d` directory, create a file named `<code>.<type>`.
`<code>` can be anything, but we recommend using a more or less unique identifier to avoid collisions, such as the branch name.
`<type>` can be `add`, `change`, `remove`, `fix`, `security` or `skip`. `skip` is only used if there is no user-visible change in the MR (for example, only editing comments in the code). Otherwise, choose a type that corresponds to your change.
In the file, write the changelog entry. For example, if an MR adds group functionality, we can create a file named `group.add` and write `Add group functionality` in it.
If one changelog entry is not enough, you may add more. But that might mean you can split it into two MRs. Only use more than one changelog entry if you really need to (for example, when one change in the code fix two different bugs, or when refactoring).https://git.pleroma.social/pleroma/pleroma/-/merge_requests/4085Include following/followers in backups2024-03-15T19:32:42Zmarcin mikołajczakInclude following/followers in backupshttps://git.pleroma.social/pleroma/pleroma/-/merge_requests/3960Add contact account to InstanceView2024-03-10T13:14:24Zmarcin mikołajczakAdd contact account to InstanceViewhttps://git.pleroma.social/pleroma/pleroma/-/merge_requests/4087Fix ffmpeg framegrabs with Exile2024-03-08T14:48:32ZfeldFix ffmpeg framegrabs with ExileWe were meant to be returning the result as `{:ok, data}` but that was overlooked when switching to Exile.We were meant to be returning the result as `{:ok, data}` but that was overlooked when switching to Exile.https://git.pleroma.social/pleroma/pleroma/-/merge_requests/3959Verify profile link ownership with rel="me"2024-03-08T00:52:17Zmarcin mikołajczakVerify profile link ownership with rel="me"Fixes #2733
### Checklist
- [x] Adding a changelog: In the `changelog.d` directory, create a file named `<code>.<type>`.Fixes #2733
### Checklist
- [x] Adding a changelog: In the `changelog.d` directory, create a file named `<code>.<type>`.https://git.pleroma.social/pleroma/pleroma/-/merge_requests/3617Preserve order of mentioned users2024-03-01T10:07:50Zmarcin mikołajczakPreserve order of mentioned usershttps://git.pleroma.social/pleroma/pleroma/-/merge_requests/4077RemoteFetcherWorker: Make sure {:error, _} is returned on failure2024-02-24T11:37:39ZHaelwennRemoteFetcherWorker: Make sure {:error, _} is returned on failureOtherwise jobs are considered a success.Otherwise jobs are considered a success.https://git.pleroma.social/pleroma/pleroma/-/merge_requests/4040Exile: switch to fork with BSD compile fix2024-02-23T20:52:37ZfeldExile: switch to fork with BSD compile fixhttps://git.pleroma.social/pleroma/pleroma/-/merge_requests/4079Exile: change to upstream pre-release commit that fixes build on FreeBSD2024-02-23T20:52:10ZfeldExile: change to upstream pre-release commit that fixes build on FreeBSD