Age | Commit message (Collapse) | Author |
|
|
|
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
|
|
mix: Check `.git` presence
See merge request pleroma/pleroma!3638
|
|
Use patern matching to see if someone was superuser before
|
|
Fix test get_user_apps/1
See merge request pleroma/pleroma!3636
|
|
Copyright bump for 2022
See merge request pleroma/pleroma!3593
|
|
|
|
When someone isn't a superuser any more, they shouldn't see the reporsts any more either.
Here we delete the report notifications from a user when that user gets updated from being a superuser to a non-superuser.
|
|
|
|
|
|
|
|
elixir gettext current does not fully support fallback to another language [0].
But it might in the future. We adapt it so that all languages in Accept-Language
headers are received by Pleroma.Web.Gettext. User.languages is now a comma-separated
list.
[0]: https://github.com/elixir-gettext/gettext/issues/303
|
|
|
|
|
|
For an example, here, zh is not supported, but zh_Hans and zh_Hant
are. If the user asks for zh, we should choose a variant for them
instead of fallbacking to default.
Some browsers (e.g. Firefox) does not allow users to customize
their language codes. For example, there is no zh-Hans, but only
zh, zh-CN, zh-TW, zh-HK, etc. This provides a workaround for
those users suffering from bad design decisions.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Revert "Merge branch 'revert/notice-routes' into 'develop'"
See merge request pleroma/pleroma!3639
|
|
This reverts merge request !3576
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Revert notice compatibility routes merge request
See merge request pleroma/pleroma!3576
|
|
|
|
|
|
For some reason I had a test who suddenly failed, mix test test/pleroma/web/o_auth/app_test.exs:54. A user has a list of applications and this test adds them and then sees if the list it gets back is the same as the apps it added.
When I ran mix test a day before I didn't have this problem and when I pushed code today in a different MR, the pipeline succeeded (see https://git.pleroma.social/ilja/pleroma/-/jobs/205827), yet locally it failed. So it seems the test can sometimes succeed and sometimes fail, which makes it untrustworthy.
The failure I see is because the returned list is in reverse order. I assume that's not per sé wrong. You just want to know if the apps you added are actually there. I fixed the test by first ordering the lists before comparing.
AFAICT (and as far as that's relevant) the test got introduced in commit cb2a072e6252b7c3f6473f7cfd1af5c0ec732d7b
|
|
|
|
|
|
|
|
https://git.pleroma.social/pleroma/pleroma-meta/-/issues/60
|
|
Unicode 14 Support
See merge request pleroma/pleroma!3633
|
|
and add a test with a unicode 14 emoji
|
|
Allow specifying max media attachment count
Closes #2665
See merge request pleroma/pleroma!3630
|
|
Signed-off-by: marcin mikołajczak <git@mkljczk.pl>
|
|
Fix tests matching on "warn"
See merge request pleroma/pleroma!3629
|
|
|
|
Moving it to "warning" would break tests on 1.12.x
|