pleroma issueshttps://git.pleroma.social/pleroma/pleroma/-/issues2023-01-05T16:50:04Zhttps://git.pleroma.social/pleroma/pleroma/-/issues/2768Exiftool may conflict with SVG files2023-01-05T16:50:04ZdebulaExiftool may conflict with SVG filesYesterday I migrated my instance to another server and enabled exiftool. Now I cannot upload SVG files any more. The server return 400 with error message:
```
{"error":" 0 image files updated\n 1 files weren't updated due to error...Yesterday I migrated my instance to another server and enabled exiftool. Now I cannot upload SVG files any more. The server return 400 with error message:
```
{"error":" 0 image files updated\n 1 files weren't updated due to errors\n"}
```
It seems that [this error message appears 11 years ago](https://exiftool.org/forum/index.php?topic=2884.0). So how can I disable it?
Update: may be related: #2522https://git.pleroma.social/pleroma/pleroma/-/issues/2766Abnormal "following" button after being blocked2022-01-09T19:03:37ZcobaltkissAbnormal "following" button after being blockedIf pleroma user A is blocked by another user B when A is still following B, the "following" button won't change into an unfollow status, which is very confusing.
I don't think it is a frontend problem cause no matter what frontend or ap...If pleroma user A is blocked by another user B when A is still following B, the "following" button won't change into an unfollow status, which is very confusing.
I don't think it is a frontend problem cause no matter what frontend or app I use, the "following" status cannot be removed.
If user B unblock user A, the "following" is still there and can't be removed either, which means A is unable to follow B after B block and unblock A.https://git.pleroma.social/pleroma/pleroma/-/issues/2764Update the caddyfile2022-03-20T18:14:01ZxerufUpdate the caddyfileCaddy v2 is out, and the caddyfile seems to not work anymore:
https://caddyserver.com/docs/v2-upgrade#caddyfile
This is my current attempt, but I get a 502 Bad Gateway, I think I am missing something:
```caddy
# default Caddyfile config...Caddy v2 is out, and the caddyfile seems to not work anymore:
https://caddyserver.com/docs/v2-upgrade#caddyfile
This is my current attempt, but I get a 502 Bad Gateway, I think I am missing something:
```caddy
# default Caddyfile config for Pleroma
domain {
log {
output file /var/log/caddy/pleroma.json
}
encode gzip
# this is explicitly IPv4 since Pleroma.Web.Endpoint binds on IPv4 only
# and `localhost.` resolves to [::0] on some systems: see issue #930
reverse_proxy / 127.0.0.1:4000
}
```https://git.pleroma.social/pleroma/pleroma/-/issues/2759Cannot report a long status2022-12-14T03:49:35ZtusooaCannot report a long status<!--
### Precheck
* For support use https://git.pleroma.social/pleroma/pleroma-support or [community channels](https://git.pleroma.social/pleroma/pleroma#community-channels).
* Please do a quick search to ensure no similar bug has been ...<!--
### Precheck
* For support use https://git.pleroma.social/pleroma/pleroma-support or [community channels](https://git.pleroma.social/pleroma/pleroma#community-channels).
* Please do a quick search to ensure no similar bug has been reported before. If the bug has not been addressed after 2 weeks, it's fine to bump it.
* Try to ensure that the bug is actually related to the Pleroma backend. For example, if a bug happens in Pleroma-FE but not in Mastodon-FE or mobile clients, it's likely that the bug should be filed in [Pleroma-FE](https://git.pleroma.social/pleroma/pleroma-fe/issues/new) repository.
-->
### Environment
* Installation type (OTP or From Source): OTP
* Pleroma version (could be found in the "Version" tab of settings in Pleroma-FE): 2.4.0
* Elixir version (`elixir -v` for from source installations, N/A for OTP): N/A
* Operating system: Ubuntu 20.04
* PostgreSQL version (`psql -V`): 13.3
### Bug description
Reporting a long status gives 500. The log is as follows:
```
05:32:01.333 [info] POST /api/v1/reports
05:32:01.404 request_id=Fp-wA_7GWAPoKQMAKEpB [error] Internal server error: %Postgrex.Error{connection_id: 1157, message: nil, postgres: %{code: :program_limit_exceeded, file: "indextuple.c", line: "185", message: "index row requires 10000 bytes, maximum size is 8191", pg_code: "54000", routine: "index_form_tuple", severity: "ERROR", unknown: "ERROR"}, query: nil}
05:32:01.404 request_id=Fp-wA_7GWAPoKQMAKEpB [info] Sent 500 in 70ms
05:32:01.408 [error] #PID<0.5300.16> running Pleroma.Web.Endpoint (connection #PID<0.5295.16>, stream id 1) terminated
Server: kazv.moe:80 (http)
Request: POST /api/v1/reports
** (exit) an exception was raised:
** (Postgrex.Error) ERROR 54000 (program_limit_exceeded) index row requires 10000 bytes, maximum size is 8191
(ecto_sql) lib/ecto/adapters/sql.ex:760: Ecto.Adapters.SQL.raise_sql_call_error/1
(ecto) lib/ecto/repo/schema.ex:725: Ecto.Repo.Schema.apply/4
(ecto) lib/ecto/repo/schema.ex:350: anonymous fn/15 in Ecto.Repo.Schema.do_insert/4
(pleroma) lib/pleroma/web/activity_pub/activity_pub.ex:180: Pleroma.Web.ActivityPub.ActivityPub.insert_activity_with_expiration/3
(pleroma) lib/pleroma/web/activity_pub/activity_pub.ex:130: Pleroma.Web.ActivityPub.ActivityPub.insert/4
(pleroma) lib/pleroma/web/activity_pub/activity_pub.ex:378: Pleroma.Web.ActivityPub.ActivityPub.do_flag/1
(ecto_sql) lib/ecto/adapters/sql.ex:1017: anonymous fn/3 in Ecto.Adapters.SQL.checkout_or_transaction/4
(db_connection) lib/db_connection.ex:1512: DBConnection.run_transaction/4
```https://git.pleroma.social/pleroma/pleroma/-/issues/2758Pleroma(PostgreSQL) seems not to use index to accelerate search for other lan...2021-08-29T18:51:56ZdebulaPleroma(PostgreSQL) seems not to use index to accelerate search for other languagesToday I successfully install `pg_jieba` extension to enable full text search for CJK.
But then I notice that the search in web page is really slow, while in `psql` console is fast.
After looking up in [source code](https://git.pleroma....Today I successfully install `pg_jieba` extension to enable full text search for CJK.
But then I notice that the search in web page is really slow, while in `psql` console is fast.
After looking up in [source code](https://git.pleroma.social/pleroma/pleroma/-/blob/develop/lib/pleroma/activity/search.ex#L82), it seems that when I search in web page, it will execute something like:
```
pleroma=# explain analyze select * from objects where to_tsvector(data->>'content') @@ websearch_to_tsquery('中文搜索') order by inserted_at desc limit 20;
-----------------------------------------------------------------------------------------------------------------------------------------
Limit (cost=34142.56..34142.57 rows=1 width=509) (actual time=12623.348..12623.404 rows=13 loops=1)
-> Sort (cost=34142.56..34142.57 rows=1 width=509) (actual time=12623.346..12623.401 rows=13 loops=1)
Sort Key: inserted_at DESC
Sort Method: quicksort Memory: 49kB
-> Gather (cost=1000.00..34142.55 rows=1 width=509) (actual time=3695.397..12623.374 rows=13 loops=1)
Workers Planned: 2
Workers Launched: 2
-> Parallel Seq Scan on objects (cost=0.00..33142.45 rows=1 width=509) (actual time=5618.056..12589.391 rows=4 loops=3)
Filter: (to_tsvector((data ->> 'content'::text)) @@ websearch_to_tsquery('
中文搜索'::text))
Rows Removed by Filter: 38638
Planning Time: 0.191 ms
Execution Time: 12623.427 ms
(12 rows)
```
or:
```
pleroma=# explain analyze select * from objects where to_tsvector(data->>'content') @@ plainto_tsquery('中文搜索') order by inserted_at desc limit 20;
-----------------------------------------------------------------------------------------------------------------------------------------
Limit (cost=34142.56..34142.57 rows=1 width=509) (actual time=13951.493..13955.684 rows=13 loops=1)
-> Sort (cost=34142.56..34142.57 rows=1 width=509) (actual time=13951.491..13955.681 rows=13 loops=1)
Sort Key: inserted_at DESC
Sort Method: quicksort Memory: 49kB
-> Gather (cost=1000.00..34142.55 rows=1 width=509) (actual time=4150.413..13955.658 rows=13 loops=1)
Workers Planned: 2
Workers Launched: 2
-> Parallel Seq Scan on objects (cost=0.00..33142.45 rows=1 width=509) (actual time=7498.200..13930.630 rows=4 loops=3)
Filter: (to_tsvector((data ->> 'content'::text)) @@ plainto_tsquery('中文搜索'::text))
Rows Removed by Filter: 38638
Planning Time: 0.148 ms
Execution Time: 13955.702 ms
(12 rows)
```
But when I specify configuration, magic appears:
```
pleroma=# explain analyze select * from objects where to_tsvector('public.jiebaqry', data->>'content') @@ plainto_tsquery('public.jiebaqry', '中文搜索') order by inserted_at desc limit 20;
---------------------------------------------------------------------------------------------------------------------------------------------------
Limit (cost=60.28..60.28 rows=1 width=509) (actual time=0.074..0.076 rows=13 loops=1)
-> Sort (cost=60.28..60.28 rows=1 width=509) (actual time=0.073..0.074 rows=13 loops=1)
Sort Key: inserted_at DESC
Sort Method: quicksort Memory: 49kB
-> Bitmap Heap Scan on objects (cost=56.00..60.27 rows=1 width=509) (actual time=0.054..0.064 rows=13 loops=1)
Recheck Cond: (to_tsvector('jiebaqry'::regconfig, (data ->> 'content'::text)) @@ '''中文'' & ''搜索'' & ''中文搜索'''::tsquery)
Heap Blocks: exact=12
-> Bitmap Index Scan on objects_fts (cost=0.00..56.00 rows=1 width=0) (actual time=0.050..0.050 rows=14 loops=1)
Index Cond: (to_tsvector('jiebaqry'::regconfig, (data ->> 'content'::text)) @@ '''中文'' & ''搜索'' & ''中文搜索'''::tsquery)
Planning Time: 0.140 ms
Execution Time: 0.096 ms
(11 rows)
pleroma=# explain analyze select * from objects where to_tsvector('public.jiebaqry', data->>'content') @@ websearch_to_tsquery('public.jiebaqry', '中文搜索') order by inserted_at desc limit 20;
---------------------------------------------------------------------------------------------------------------------------------------------------
Limit (cost=60.28..60.28 rows=1 width=509) (actual time=0.093..0.095 rows=13 loops=1)
-> Sort (cost=60.28..60.28 rows=1 width=509) (actual time=0.092..0.094 rows=13 loops=1)
Sort Key: inserted_at DESC
Sort Method: quicksort Memory: 49kB
-> Bitmap Heap Scan on objects (cost=56.00..60.27 rows=1 width=509) (actual time=0.068..0.081 rows=13 loops=1)
Recheck Cond: (to_tsvector('jiebaqry'::regconfig, (data ->> 'content'::text)) @@ '''中文'' & ''搜索'' & ''中文搜索'''::tsquery)
Heap Blocks: exact=12
-> Bitmap Index Scan on objects_fts (cost=0.00..56.00 rows=1 width=0) (actual time=0.062..0.062 rows=14 loops=1)
Index Cond: (to_tsvector('jiebaqry'::regconfig, (data ->> 'content'::text)) @@ '''中文'' & ''搜索'' & ''中文搜索'''::tsquery)
Planning Time: 0.162 ms
Execution Time: 0.116 ms
(11 rows)
```
That's weird. The server knows the exact text search configuration, but it doesn't use the index of it. Although it is easy to fix it, I still have no idea why this thing happens.
PostgreSQL: 13+226.pgdg16.04+1
Pleroma: 2.3.0-1-gb221d77ahttps://git.pleroma.social/pleroma/pleroma/-/issues/2757The default timeout for `database set_text_search_config` is too short2021-08-30T08:19:22ZdebulaThe default timeout for `database set_text_search_config` is too shortToday I want to enable text search for CJK: https://docs.pleroma.social/backend/configuration/howto_search_cjk/
But when I execute `./bin/pleroma_ctl database set_text_search_config pg_jieba`, it always return timeouts.
It turns out th...Today I want to enable text search for CJK: https://docs.pleroma.social/backend/configuration/howto_search_cjk/
But when I execute `./bin/pleroma_ctl database set_text_search_config pg_jieba`, it always return timeouts.
It turns out that the last step - creating GIN index for toots - usually spends more time than the default timeout (15s). After I prune the database to around 110,000 toots, I finally pass this limitation.
References:
- https://git.pleroma.social/pleroma/pleroma/-/blob/develop/lib/mix/tasks/pleroma/database.ex#L220
- https://hexdocs.pm/ecto/2.2.8/Ecto.Adapters.SQL.html#query/4-optionshttps://git.pleroma.social/pleroma/pleroma/-/issues/2756Cannot enable text search for CJK with `pg_jieba`2021-08-26T03:08:01ZdebulaCannot enable text search for CJK with `pg_jieba`Hi! I try to follow the docs to enable text search: https://docs.pleroma.social/backend/configuration/howto_search_cjk/ .
For the convenience I use [pg_jieba](https://github.com/jaiminpan/pg_jieba).
After `make install` and `create ext...Hi! I try to follow the docs to enable text search: https://docs.pleroma.social/backend/configuration/howto_search_cjk/ .
For the convenience I use [pg_jieba](https://github.com/jaiminpan/pg_jieba).
After `make install` and `create extension pg_jieba;`, it works with `ts_debug`. So I try:
```
./bin/pleroma_ctl database set_text_search_config public.jiebacfg
```
but it returns errors:
```
Current default_text_search_config: pg_catalog.english
Update default_text_search_config: public.jiebacfg
Error: [
%{
code: "42704",
file: "ts_cache.c",
line: "617",
message: "text search config \"public.jiebacfg\" does not exist",
routine: "check_TSCurrentConfig",
...
}
]
```
After restart Pleroma and PostgreSQL, this issue still exists. That's weird. I can see it in psql console with command `\dF`, but I can't set it as default search configuration.
Pleroma: 2.3.0-1-gb221d77ahttps://git.pleroma.social/pleroma/pleroma/-/issues/2754Pleroma crashed and fails to restart2021-08-22T21:48:09ZcptnPleroma crashed and fails to restart<!--
### Precheck
* For support use https://git.pleroma.social/pleroma/pleroma-support or [community channels](https://git.pleroma.social/pleroma/pleroma#community-channels).
* Please do a quick search to ensure no similar bug has been ...<!--
### Precheck
* For support use https://git.pleroma.social/pleroma/pleroma-support or [community channels](https://git.pleroma.social/pleroma/pleroma#community-channels).
* Please do a quick search to ensure no similar bug has been reported before. If the bug has not been addressed after 2 weeks, it's fine to bump it.
* Try to ensure that the bug is actually related to the Pleroma backend. For example, if a bug happens in Pleroma-FE but not in Mastodon-FE or mobile clients, it's likely that the bug should be filed in [Pleroma-FE](https://git.pleroma.social/pleroma/pleroma-fe/issues/new) repository.
-->
### Environment
* Installation type (OTP or From Source): Source
* Pleroma version (could be found in the "Version" tab of settings in Pleroma-FE): 2.4.0
* Elixir version (`elixir -v` for from source installations, N/A for OTP): Erlang/OTP 23 & Elixir 1.11.2
* Operating system: Debian 10
* PostgreSQL version (`psql -V`): 11.9
### Bug description
Pleroma worked fine since the 2.4.0 release two weeks ago. Today I couldn't post or upload attachments today so restarted pleroma. Now it fails to restart. I've already tried restarting the server itself as well as mix.clean --all and recompiling.
```
● pleroma.service - Pleroma social network
Loaded: loaded (/etc/systemd/system/pleroma.service; enabled; vendor preset: enabled)
Active: active (running) since Sun 2021-08-22 17:10:51 UTC; 1min 35s ago
Main PID: 1165 (beam.smp)
Tasks: 31 (limit: 4915)
Memory: 252.0M
CGroup: /system.slice/pleroma.service
├─1165 /usr/lib/erlang/erts-11.1.5/bin/beam.smp -- -root /usr/lib/erlang -progname erl -- -home /var/lib/pleroma -- -pa /usr/lib/elixir/bin/../lib/eex/ebin /usr/lib/elixir/bin/../lib/elixir/ebin /usr/lib/elixir/bin/../lib/ex_unit/ebin /usr/lib/elixir/bin/../lib/iex/ebin /usr/lib/elixir/bin/../lib/logger/ebin /usr/lib/elixir/bin/../lib/mix/ebin -noshell -s elixir start_cli -extra /usr/bin/mix phx.server
├─1180 erl_child_setup 1024
├─1225 /opt/pleroma/_build/prod/lib/fast_html/priv/fasthtml_worker
├─1226 /opt/pleroma/_build/prod/lib/fast_html/priv/fasthtml_worker
├─1227 /opt/pleroma/_build/prod/lib/fast_html/priv/fasthtml_worker
├─1231 inet_gethost 4
├─1232 inet_gethost 4
└─1250 /opt/pleroma/_build/prod/lib/fast_html/priv/fasthtml_worker
Aug 22 17:11:05 vps mix[1165]: (kernel 7.2) application_master.erl:277: :application_master.start_it_old/4
Aug 22 17:11:05 vps mix[1165]: 17:11:05.362 [error] GenServer Restarter.Pleroma terminating
Aug 22 17:11:05 vps mix[1165]: ** (MatchError) no match of right hand side value: {:error, {:bad_return, {{Pleroma.Application, :start, [:normal, []]}, {:EXIT, {%Pleroma.ApplicationRequirements.VerifyError{message: "System commands missing. Check logs and see `docs/installation` for more details."}, [{Pleroma.ApplicationRequirements, :handle_result, 1, [file: 'lib/pleroma/application_requirements.ex', line: 32]}, {Pleroma.Application, :start, 2, [file: 'lib/pleroma/application.ex', line: 56]}, {:application_master, :start_it_old, 4, [file: 'application_master.erl', line: 277]}]}}}}}
Aug 22 17:11:05 vps mix[1165]: (restarter 0.1.0) lib/pleroma.ex:92: Restarter.Pleroma.do_restart/1
Aug 22 17:11:05 vps mix[1165]: (restarter 0.1.0) lib/pleroma.ex:84: Restarter.Pleroma.handle_cast/2
Aug 22 17:11:05 vps mix[1165]: (stdlib 3.14) gen_server.erl:689: :gen_server.try_dispatch/4
Aug 22 17:11:05 vps mix[1165]: (stdlib 3.14) gen_server.erl:765: :gen_server.handle_msg/6
Aug 22 17:11:05 vps mix[1165]: (stdlib 3.14) proc_lib.erl:226: :proc_lib.init_p_do_apply/3
Aug 22 17:11:05 vps mix[1165]: Last message: {:"$gen_cast", {:after_boot, :prod}}
Aug 22 17:11:05 vps mix[1165]: State: %{after_boot: false, need_reboot: false, rebooted: false}
```https://git.pleroma.social/pleroma/pleroma/-/issues/2753tons of errors like "Could not decode user at fetch https://mastodonspain.mas...2023-11-01T09:01:32ZMoon Mantons of errors like "Could not decode user at fetch https://mastodonspain.masto.host/actor, :checkout_timeout"on latest release. log is filled with these for various servers, and incoming and outgoing messages were not received. A restart fixed it.on latest release. log is filled with these for various servers, and incoming and outgoing messages were not received. A restart fixed it.https://git.pleroma.social/pleroma/pleroma/-/issues/2749Let users who didn't have emails to add emails2021-09-23T06:40:00ZcobaltkissLet users who didn't have emails to add emailsThere are many people in my instance that did not write down emails when they signed up.
Since account backups require users to have emails, users who didn't have emails will not be able to get their backups.
Users can change email when ...There are many people in my instance that did not write down emails when they signed up.
Since account backups require users to have emails, users who didn't have emails will not be able to get their backups.
Users can change email when they don't want to use their old email addresses, and I suggest we let them add new emails if they had left the email line blank.
If pleroma already made it possible, please tell me how to do it. Thank you.https://git.pleroma.social/pleroma/pleroma/-/issues/2748How to use the followbot in 2.4.0 actually? How to know it followed how many ...2021-08-14T10:27:56ZSnowHow to use the followbot in 2.4.0 actually? How to know it followed how many people?I didn't see the document mentioned... Just adding "Pleroma.Web.ActivityPub.MRF.FollowBotPolicy" into MRF?
https://rage.lol/notice/AAIWu60mjOtQ4uFB9UI didn't see the document mentioned... Just adding "Pleroma.Web.ActivityPub.MRF.FollowBotPolicy" into MRF?
https://rage.lol/notice/AAIWu60mjOtQ4uFB9Uhttps://git.pleroma.social/pleroma/pleroma/-/issues/2746User cannot delete their account2021-12-15T21:26:47ZtusooaUser cannot delete their account<!--
### Precheck
* For support use https://git.pleroma.social/pleroma/pleroma-support or [community channels](https://git.pleroma.social/pleroma/pleroma#community-channels).
* Please do a quick search to ensure no similar bug has been ...<!--
### Precheck
* For support use https://git.pleroma.social/pleroma/pleroma-support or [community channels](https://git.pleroma.social/pleroma/pleroma#community-channels).
* Please do a quick search to ensure no similar bug has been reported before. If the bug has not been addressed after 2 weeks, it's fine to bump it.
* Try to ensure that the bug is actually related to the Pleroma backend. For example, if a bug happens in Pleroma-FE but not in Mastodon-FE or mobile clients, it's likely that the bug should be filed in [Pleroma-FE](https://git.pleroma.social/pleroma/pleroma-fe/issues/new) repository.
-->
### Environment
* Installation type (OTP or From Source): OTP (docker)
* Pleroma version (could be found in the "Version" tab of settings in Pleroma-FE): 2.4.0
* Elixir version (`elixir -v` for from source installations, N/A for OTP): N/A
* Operating system: Docker image on Ubuntu 20.04
* PostgreSQL version (`psql -V`): psql (PostgreSQL) 13.3 (at https://lily.kazv.moe/infra/postgres/-/blob/servant/Dockerfile )
### Bug description
When I try to delete account in Pleroma-FE, it reports "Invalid credentials." I am sure that I entered the password correctly.https://git.pleroma.social/pleroma/pleroma/-/issues/2744Impossible to view reposts for which no Create activity exists?2021-08-14T22:31:52ZAlex GleasonImpossible to view reposts for which no Create activity exists?Digging into the code for MastodonAPI.StatusView I notice it really tries to get the `Create` activity for all reposts...
```elixir
parent_activities =
activities
|> Enum.filter(&(&1.data["type"] == "Announce" && &1.data...Digging into the code for MastodonAPI.StatusView I notice it really tries to get the `Create` activity for all reposts...
```elixir
parent_activities =
activities
|> Enum.filter(&(&1.data["type"] == "Announce" && &1.data["object"]))
|> Enum.map(&Object.normalize(&1, fetch: false).data["id"])
|> Activity.create_by_object_ap_id()
|> Activity.with_preloaded_object(:left)
|> Activity.with_preloaded_bookmark(reading_user)
|> Activity.with_set_thread_muted_field(reading_user)
|> Repo.all()
```
This is in `"index.json"` and the `Activity.create_by_object_ap_id()` is the important part here.
What if there's is no `Create`? You only get the `Create` if the origin server sent it to you, and you won't get it from an `Announce`.
How is this even working right now? It seems like it really shouldn't be able to, and it's causing errors on my Groups branch. I'm going to refactor this.
Related to !3508https://git.pleroma.social/pleroma/pleroma/-/issues/2743Function request: "Post didn't arrive to the instance"2021-08-14T10:45:19ZSnowFunction request: "Post didn't arrive to the instance"Since poa.st blocking some people from other instance for no reason at all... And I think they didn't tell all people to know who is blocked.
I think those people could still @ users in poa.st, therefore they need to know themselves are...Since poa.st blocking some people from other instance for no reason at all... And I think they didn't tell all people to know who is blocked.
I think those people could still @ users in poa.st, therefore they need to know themselves are blocked for avoiding more misunderstanding.https://git.pleroma.social/pleroma/pleroma/-/issues/2742Transmogrifier.fix_explicit_addressing/2 is confusing me2021-08-11T19:27:22ZAlex GleasonTransmogrifier.fix_explicit_addressing/2 is confusing meFrom the looks of it, `Transmogrifier.fix_explicit_addressing/2` will find any mentions under `"tags"` and modify the `"to"` field to add those mentions.
This has been confusing to me while developing Groups. A post "to" a group belongs...From the looks of it, `Transmogrifier.fix_explicit_addressing/2` will find any mentions under `"tags"` and modify the `"to"` field to add those mentions.
This has been confusing to me while developing Groups. A post "to" a group belongs in the group, but a *mention* of the group does not.
In a completely different conversation, [a user was asking](https://gleasonator.com/@KayFaraday@pedo.school/posts/AADvQWhhRVAhRfO9mC) if we could use MRF to prevent local activities from being delivered to rejected instances. I figured we could drop them from the `"to"` field, but then Pleroma would just add them back to it again with `fix_explicit_addressing/2`.
Why are we doing this? I'm sure there's a good reason. Do we believe mentions are inseparable from the `"to"` field? Compatibility with other implementations? etchttps://git.pleroma.social/pleroma/pleroma/-/issues/2741Is there any place to post custom MRFs?2021-08-11T17:19:07ZSnowIs there any place to post custom MRFs?Theoretically, the custom MRFs should be shared, right?
https://docs-develop.pleroma.social/backend/configuration/mrf/#writing-your-own-mrf-policyTheoretically, the custom MRFs should be shared, right?
https://docs-develop.pleroma.social/backend/configuration/mrf/#writing-your-own-mrf-policyhttps://git.pleroma.social/pleroma/pleroma/-/issues/2740Pleroma users (admin & ordinary) cannot change password via pleroma-fe (API 4...2021-09-06T00:36:06ZmindofjoePleroma users (admin & ordinary) cannot change password via pleroma-fe (API 400/Bad Request)**Environment**
1. pleroma 2.4.0-516-gdc63aaf8 (OTP), pulled *today* via <code>curl "https://git.pleroma.social/api/v4/projects/2/jobs/artifacts/stable/download?job=amd64" -o pleroma_amd64.zip</code>
2. **OS**: Ubuntu 20.04.2 LTS (64-bi...**Environment**
1. pleroma 2.4.0-516-gdc63aaf8 (OTP), pulled *today* via <code>curl "https://git.pleroma.social/api/v4/projects/2/jobs/artifacts/stable/download?job=amd64" -o pleroma_amd64.zip</code>
2. **OS**: Ubuntu 20.04.2 LTS (64-bit)
2. **Browser**: firefox 90.0.2 (64-bit) for Ubuntu canonical 1.0
**Issue**
1. Install looks fine. Access with browser looks fine.
2. Admin new user via CLI and login via browser, no problem.
3. New user (non-admin) creation via pleroma-fe, no problem.
4. *Neither admin nor ordinary user can use pleroma-fe to change password.*
5. The issue is the same whether using AdminFE or not.
**What I see**
1. POST is made to <code>/api/pleroma/change_password</code> with response 400 / Bad Request.
2. UI indicates each of <code>password</code>, <code>new_password</code>, and <code>new_password_confirmation</code> are missing.
3. Request does contain form-data; name="password" "new_password" and "new_password_confirmation" data is present as entered in the form.
4. Response contains an error object indicating the missing data, as well as a list of three items, one for each field, indicating pointers <code>/password</code>, <code>/new_password</code>, and <code>/new_password_confirmation</code> have titles <code>Invalid value</code>.
**What I expect**
1. Successful password change and confirmation.
I searched "password" on both pleroma & pleroma-fe gitlab for "password" without any luck. I posted the issue to #pleroma @ libera.chat today without response. Raising the issue here as a result.
I've successfully installed have been using a single-user pleroma instance for several months, so I haven't had cause to detect when this issue may have appeared. I spotted this running some tests for a new potentially multi-user install.
How can I help?2.4.1HaelwennHaelwennhttps://git.pleroma.social/pleroma/pleroma/-/issues/2735[2.4.0 stable] No available Frontends2021-08-09T08:23:27ZSnow[2.4.0 stable] No available FrontendsSo...what is the point of this??
![9d65b84aff](/uploads/c17c780ea27ceb1c706bdd110513d185/9d65b84aff.png)So...what is the point of this??
![9d65b84aff](/uploads/c17c780ea27ceb1c706bdd110513d185/9d65b84aff.png)https://git.pleroma.social/pleroma/pleroma/-/issues/2734[2.4.0 stable] unable to use the external button on the top of the profile.2021-08-09T08:08:42ZSnow[2.4.0 stable] unable to use the external button on the top of the profile.![2021-08-09-15-09-38](/uploads/e639ad28e5946726aea7a6e88ed64371/2021-08-09-15-09-38.webm)![2021-08-09-15-09-38](/uploads/e639ad28e5946726aea7a6e88ed64371/2021-08-09-15-09-38.webm)https://git.pleroma.social/pleroma/pleroma/-/issues/2733Support green checkmark (rel="me") in profile fields2024-03-08T00:52:12ZAlex GleasonSupport green checkmark (rel="me") in profile fieldsI did not know Pleroma already had the ability to scrape links for `rel="me"` introduced by !813. With this, it should be fairly easy to support the green checkmark for custom profile fields like Mastodon does. All we're missing is `veri...I did not know Pleroma already had the ability to scrape links for `rel="me"` introduced by !813. With this, it should be fairly easy to support the green checkmark for custom profile fields like Mastodon does. All we're missing is `verified_at`, which shouldn't even require schema changes to add.
```js
"fields": [
{
"name": "Website",
"value": "<a href=\"https://trwnh.com\" rel=\"me nofollow noopener noreferrer\" target=\"_blank\"><span class=\"invisible\">https://</span><span class=\"\">trwnh.com</span><span class=\"invisible\"></span></a>",
"verified_at": "2019-08-29T04:14:55.571+00:00"
},
{
"name": "Sponsor",
"value": "<a href=\"https://liberapay.com/at\" rel=\"me nofollow noopener noreferrer\" target=\"_blank\"><span class=\"invisible\">https://</span><span class=\"\">liberapay.com/at</span><span class=\"invisible\"></span></a>",
"verified_at": "2019-11-15T10:06:15.557+00:00"
},
{
"name": "Fan of:",
"value": "Punk-rock and post-hardcore (Circa Survive, letlive., La Dispute, THE FEVER 333)Manga (Yu-Gi-Oh!, One Piece, JoJo's Bizarre Adventure, Death Note, Shaman King)Platformers and RPGs (Banjo-Kazooie, Boktai, Final Fantasy Crystal Chronicles)",
"verified_at": null
},
{
"name": "Main topics:",
"value": "systemic analysis, design patterns, anticapitalism, info/tech freedom, theory and philosophy, and otherwise being a genuine and decent wholesome poster. i'm just here to hang out and talk to cool people!",
"verified_at": null
}
]
```