Display public favorites #390
No reviewers
Labels
No labels
a11y
Bug
Bug fix
cannot reproduce
CSS
Documentation
enhancement
Feature
Feature request
Held for next release cycle
Minor change
performance
priority: critical
priority: high
priority: low
priority: medium
priority: patch welcome
regression
Translation/Locale
WIP
No milestone
No project
No assignees
2 participants
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
AkkomaGang/akkoma-fe!390
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "lamp/akkoma-fe:public-favorites"
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?
closes #389
Thanks for porting this! I haven’t looked closely at this yet, but i think the attribution needs to be clearer. Both because attibuting original authors is the nice thing to do and because not doing so can become legally problematic.
iiuc the first commit ports over the two Pleroma PRs linked in the issue and those original commit hashes are mentioned in the commit messages. However, (a) there’s no information about the original author, (b) those commits don’t exists in akkoma-fe and thus can’t be easily looked up and (c) afaiu you’re not the original author of those patches.
If the original commits applied cleanly or only with minor changes. ideally they’d ideally retain the original primary author, possibly with an added
Cherry-picked-from:line. (e.g. by exporting from pleroma-fe withgit format-patchand then applying to akkoma-fe withgit am, or just usinggit commit --amend --author="...")If significant changes were needed, it’s probably fine to keep yourself as the primary author, but you should at least add something like this to the commit message:
893ce69a1b4d91a7b2c3ok i
The basics seem good to me except for one change to potentially clean things up a bit
@ -117,2 +120,2 @@// only we can see our own favouritesif (this.isUs) timelineTabMap['favorites'] = 'favorites'if (this.favoritesTabVisible) timelineTabMap['favorites'] = 'favorites'provided it works well with
user_profile.vue(not sure tbh; frontend stuff isn’t my strong suit), it would imho be cleaner to properly distinguish one’s own favourites from publicly accessible favourites here and get rid off theuserIdchecks and mangling in the other parts, i.e.:i tried this but weird stuff happened
oh also, can you add:
Fixes: https://akkoma.dev/AkkomaGang/akkoma-fe/issues/389as the last line of the commit message? This way the issue will be closed automatically (just mentioning it in the PR comment doesn't actually to work ime)I merged the update. Now I can't figure out why are the public favorites being sorted?
// Keep the visible statuses sortedif (timeline && !(['bookmarks', 'favorites'].includes(timeline))) {sortTimeline(timelineObject)}timeline should be 'favorites' regardless. but it is only not sorting when I'm logged in.
Your own favs are paginated by like ids (≈date of liking the post); most other timelines are sorted by post id (≈date of post (or when it was fetched for remote posts)). Resorting own favs by id of the posts destroys the intended order and causes judder as new entries are added at various different places
ohh it's the backend serving them like this. frontend is not sorting them like it's supposed not to.
So the favorites from /api/v1/pleroma/accounts/:id/favourites are ordered by post date while from /api/v1/favourites are ordered by favourite date. ugh. so this is pleroma issue..
Fix public favoritesto Display public favoritesView command line instructions
Checkout
From your project repository, check out a new branch and test the changes.