In preparation to an eventual switch to native Masto API format,
as well as flexibility to backends without the extension,
the entity normaliser just copies the count paramter to the same path
The current user info fetcher will also be used for
total unread DM counts in the future.
To avoid any future mishaps with improperly stopped fetchers etc,
this does not use the existing 'setCurrentUser' method but a new
update method with a safeguard against accidentally changing the
identity.
This replaces the removed "direct" timeline.
Curtnetly this is a read-only interface missing ways to
mark conversations as read, dismiss/delete conversations
or modify the core members of a conversation.
Future work may also add QoL stuff like automatic implicit addressing of
core members or (provided another backend extension) add messages to a
conversation without replying to something particular.
It has been long deprecated and even already removed from Mastodon
and our existing implementation suffers from bugs (at least on
large/some instances), see:
AkkomaGang/akkoma#798
Except for pleroma-derived web frontends, other clients generally don't
seem to make use of this timeline either, often also omitting an
interface for the conversations API.
Even if it worked properly, this isn’t the best way to present
DMs as all threads with different participants or topics are mixed
together in one linear timeline. The conversations API which suceeded
it in Mastodon and our backend already supports offers a much better
interface.
Fixes regression in f2c55423fd.
Ideally, this would only set state for what was actually changed
rather than rewriting the entire storage each time, which would also
have avoided this issue.
The fix is somehwat hacky not working with an empty path list or
parsed/internal fields not at the top-level of a path, but in practice
this seems to be always called with well bheaving paths. Should this ever
become an issue, this should migrating to the overall saner updating
approach described in the preceding paragraph.
Note: the cloneDeep call was originally added in
a97c07bfdf as part of
https://git.pleroma.social/pleroma/pleroma-fe/-/merge_requests/1385
Though it is not clear why setState would mangle its data argument
as it supposedly does to necessitate this copying.
As of Node 25, corepack will no longer be included by default in
the distribution:
https://github.com/nodejs/TSC/pull/1697
A separate corepack package is already available in npm, which
should work the same as the corepack that was included in Node 24
and prior.
The rest of the build instructions should remain the same.
This makes any filter that starts and ends in forward slashes act as a
regex filter instead of a simple substring filter.
In case any existing plain-text rule already matches this
it will need to be updated adding an additional layer of slashes
and escapes as needed. However, this is thought to be sufficiently uncommon.
Instead of using trailing flags as modifier complicating parsing further,
any modifications to regex matching must be done via local modifiers. See
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Regular_expressions/Modifier
Visibility scopes have no total order, but the function signature
of a compare function implies/requires such.
This led to the scope selector showing "local" as a possible option
on some original post scopes it was not actually compatible with.
The negotiated initially selected value was already correct though.
Was noticeable by e.g. the scrollbar being shown somewhere inside the
container and not being able to scroll near the edges if each line of
text was sufficiently short.
Directly implements the suggesstion from
AkkomaGang/akkoma-fe#456 (comment)
The upload call hid errors and the entity normaliser lets them pass
through as well (assuming it must be an already "correctly" formatted
legacy qvitter response), which led to errors being added to the the
draft as if it was a valid attachment object.
On later use of this error exceptions occur breaking the frontend and
due to being saved as part of a draft this could only be recovered by
clearing local client data.
Fixes: AkkomaGang/akkoma-fe#339
This is the canonical reference to a post and works best for lookups on
other servers. Previously this canonical ID was not accessible from the
frontend at all.
The "source" button continues to redirect to the preferred display URL
though (if set), since this is as the name suggests the preferred URL
for viewing the post in a browser (it might however not work when the
source instance restricts unauthenticated access even to local content).
This lifts the redundancy between the "source" and "copy link" buttons.
Since the legac qvitter API is still accounted for in the entity
normaliser, we just assume its external_url serves as both the canoncial
location and preferred display URL. It is dubious however, if this
codepath can even still be triggered at all and it likely makes more
sense to purge all remnants of the legacy API from the codebase.
Resolves: AkkomaGang/akkoma-fe#166
This reverts commit e1b4d8f59a
and obsoletes commit c2db0e66ef
which already unset min-height in notifications where this
caused images to become effectively invisible.
Image previews are currently designed to always show the full image
scaled down as needed. With min-height though they were allowed to
take the full width even if it caused overflows in vertical direction.
This happened to look kind of fine with only easy-to-miss overflows
in the main post view if each preview row had the same amount of
columns, but creates jarring overlaps otherwise.
Fixes: AkkomaGang/akkoma-fe#456
The media modal was changed to use still_image, but the attribute
pointing to the image load event handler wasn't updated.
This causes the modal to remain in the loading state forever.
Fixes: f48138c979
Instead, just also prefill the text wuth the user handle
for pure mentions.
This lead to us sending a boolean status id to the backend
which presumably only didn't cause problems in *oma backends
because API spec validation dropped the value with a mismatched type.
On an Iceshrimp.NET backend this caused errors to pop up.
There are more conditions gated by replyTo in the post form but
no longer triggering them doesn't seem to have any noticeable effect.
The one noticeable change being mentions now share a draft save slot
with regular message composing (before all mention messages shared the
same reply:true slot), but this seems sensible enough.
At least modern versions of corepack'ed yarn
(as build instructions tell use to use)
reaaally want to add this to the lockfile,
so let it do so to not need to constantly
be wary of uncommited changes here.
We don’t need them after initial account registration
and they just clutter the database otherwise
Together with the preceding commit this should get the
flood of garbage tokens into our database under control.
(We still want to fix the backends cleanup of old,
already existing tokens though)
Fixes: AkkomaGang/akkoma-fe#429
Original commit amended with a fix for registrations;
they need to (now) create an app and fetch an app-only token
before doing anything else, as this endpoint requires such a token.
Co-authored-by: Oneric <oneric@onierc.stub>
Cherry-picked-from: 0e25b94186
This only worked in *oma due to legacy session-cookie auth kicking in
(which we should really get around to fully purge).
Cherry-picked-from: e8896fad15
The frontend assumes these URLs will be relative to the target instance,
which may not be the case for non-*oma backends like Iceshrimp.NET
due to the backend storing emoji in an external object storage depending
on configuration.
Cherry-picked-from: c147c2aeb3
