fedward/distraction.party
1
0
Fork 0
forked from AkkomaGang/akkoma
Code Issues Pull requests Packages Projects Releases Wiki Activity

Merge upstream changes from stable #3

Merged
fedward merged 57 commits from AkkomaGang/akkoma:stable into stable 2022-11-15 15:35:25 +00:00
Conversation 0 Commits 57 Files changed 75 +2101 -518
fedward commented 2022-11-15 15:34:59 +00:00
Owner
Copy link

Merge upstream changes to stable branch

Merge upstream changes to stable branch
fedward added 57 commits 2022-11-15 15:35:00 +00:00 
Co-authored-by: FloatingGhost <hannah@coffee-and-dreams.uk>
Reviewed-on: AkkomaGang/akkoma#231
from https://git.pleroma.social/pleroma/pleroma/-/merge_requests/3647/

Co-authored-by: marcin mikołajczak <git@mkljczk.pl>
Co-authored-by: Tusooa Zhu <tusooa@kazv.moe>
Co-authored-by: FloatingGhost <hannah@coffee-and-dreams.uk>
Reviewed-on: AkkomaGang/akkoma#232
It was tested if the updated_at after marking as "read" was equal as the updated_at at insertion, but that seems wrong.
Firstly, if a record is updated, you expect the updated_at to also update.
Secondly, the insert and update happen almost at the same time, so it's flaky regardless.

Here I make sure it has a much older updated_at during insert so we can clealy see the effect after update.
I also check that the updated_at is actually updated because I expect that this is the expected behaviour and it's also the current behaviour.
The problem was double. On the one hand, the function didn't actually return what was in the DB.
On the other hand the test was flaky because it used NaiveDateTime.utc_now() so test could fail or pass depending on a difference of microseconds.

Both are fixed now.
Signed-off-by: marcin mikołajczak <git@mkljczk.pl>
Simple fix for LDAP user registration. I'm not sure what changed but I managed to get Akkoma running in a debug session and figured out it was missing a match for an extra value at the end. I don't know Elixir all that well so I'm not sure if this was the correct way to do it... but it works. :)

Reviewed-on: AkkomaGang/akkoma#229
Co-authored-by: nullobsi <me@nullob.si>
Co-committed-by: nullobsi <me@nullob.si>
Fixes one of the 'erratic' tests

It used a timer to sleep.
But time also goes on when doing other things, so depending on hardware, the timings could be off.
I slightly changed the tests so we still test what we functionally want.
Instead of waiting until the cache expires I now have a function to expire the test and use that.

That means we're not testing any more if the cache really expires after a certain amount of time,
but that's the responsability of the dependency imo, so shouldn't be a problem.

I also changed `Pleroma.Web.Endpoint, :http, :ip` in the tests to `127.0.0.1`
Currently it was set to 8.8.8.8, but I see no reason for that and, while I assume that no calls
are made to it, it may come over as weird or suspicious to people.

Co-authored-by: Ilja <ilja@ilja.space>
Reviewed-on: AkkomaGang/akkoma#233
Co-authored-by: ilja <akkoma.dev@ilja.space>
Co-committed-by: ilja <akkoma.dev@ilja.space>
There were async calls happening, so they weren't always finished when assert happened.

I also fixed some bugs in the erratic tests that were introduced when removing :shout.:shout is a key where restart is needed, and was changed in the test to use :rate_limit (which also requires a restart). But there was a bug in the syntax that didn't get caught because the test was tagged as erratic and therefor didn't fail. Here I fixed it.

During compilation, we had a warning `:logger is used by the current application but the current application does not depend on :logger` which is now fixed as well (see commit message for complete stacktrace).

Co-authored-by: Ilja <ilja@ilja.space>
Reviewed-on: AkkomaGang/akkoma#237
Co-authored-by: ilja <akkoma.dev@ilja.space>
Co-committed-by: ilja <akkoma.dev@ilja.space>
Reviewed-on: AkkomaGang/akkoma#238
Reviewed-on: AkkomaGang/akkoma#239
Reviewed-on: AkkomaGang/akkoma#240
Reviewed-on: AkkomaGang/akkoma#244
This was left at "Pleroma" for some reason.
Reviewed-on: AkkomaGang/akkoma#248
Fixes pleroma-fe#185
The header name was Report-To, not Reply-To.

In any case, that's now being changed to the Reporting-Endpoints HTTP
Response Header.
https://w3c.github.io/reporting/#header
https://github.com/w3c/reporting/issues/177

CanIUse says the Report-To header is still supported by current Chrome
and friends.
https://caniuse.com/mdn-http_headers_report-to

It doesn't have any data for the Reporting-Endpoints HTTP header, but
this article says Chrome 96 supports it.
https://web.dev/reporting-api/

(Even though that's come out one year ago, that's not compatible with
Network Error Logging which's still using the Report-To version of the
API)

Signed-off-by: Thomas Citharel <tcit@tcit.fr>
Reviewed-on: AkkomaGang/akkoma#250
Co-authored-by: FloatingGhost <hannah@coffee-and-dreams.uk>
Reviewed-on: AkkomaGang/akkoma#251
fixes #235
fixes #228

Co-authored-by: FloatingGhost <hannah@coffee-and-dreams.uk>
Reviewed-on: AkkomaGang/akkoma#254
Co-authored-by: FloatingGhost <hannah@coffee-and-dreams.uk>
Reviewed-on: AkkomaGang/akkoma#260
Currently translated at 21.6% (23 of 106 strings)

Co-authored-by: mint <they@mint.lgbt>
Translate-URL: http://translate.akkoma.dev/projects/akkoma/akkoma-backend-errors/es/
Translation: Pleroma fe/Akkoma Backend (Errors)
Updated by "Squash Git commits" hook in Weblate.

Translation: Pleroma fe/Akkoma Backend (Errors)
Translate-URL: http://translate.akkoma.dev/projects/akkoma/akkoma-backend-errors/
Reviewed-on: AkkomaGang/akkoma#262
Reviewed-on: AkkomaGang/akkoma#266
fedward merged commit 4ce8dd6d3d into stable 2022-11-15 15:35:25 +00:00
Sign in to join this conversation.
Reviewers
No reviewers
Labels
Clear labels
No items
No labels
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference: fedward/distraction.party#3
No description provided.
Delete branch "AkkomaGang/akkoma:stable"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?