`git flow release finish` opened the editor three times, and the content was
never edited: twice for the merge commits, where the message generated by git is
always kept, and once for the message of the annotated tag, where a placeholder
was typed by hand. The last tags carry the message "tag" for that reason.
GIT_MERGE_AUTOEDIT=no keeps the merge messages git already generates, and -m
provides the tag message. git flow appends the tag name to that message, so the
tag of the next release will read "Release v26.09.0".
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
releaseV2.sh is a copy of release.sh in which the GitHub CLI is mandatory and
does what was previously done by hand: it finds and waits for the release.yml
run, downloads and extracts its artifacts, creates the pre-release with its 6
assets and the generated release notes, and prepends those notes to CHANGES.md.
It also compares the version code and version name of the signed artifacts to
the expected values instead of asking the user to check them, and no longer
needs ELEMENT_GITHUB_TOKEN, since the CLI uses its own credentials. release.sh
is left untouched, so that the next release can be done with releaseV2.sh while
keeping a way back if something goes wrong. The installation documentation is
also fixed, as it referred to an asset name that does not exist anymore.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
The raw push rules returned by the SDK are a single long line of json, which is
hard to read on a phone. Re-encode the content with a pretty printer using a two
space indentation before handing it to the file viewer.
Parsing to a JsonElement and re-encoding preserves the order of the keys, so the
rules are still listed in the order the server returned them. Content which
cannot be parsed is passed through unchanged, so that a malformed payload remains
viewable.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Add a "Push rules" item in the Notifications section of the developer options,
above "Push history". It displays the raw push rules of the account, which were
only available as a rageshake attachment so far.
The content is read using NotificationSettingsService.getRawPushRules(), then
rendered by the new FileViewerEntryPoint, so that the screen looks like the media
viewer rendering a file, with Share and Download actions on a
push_rules<userId>.json file. The user id contains a colon, which is not a valid
file name character on all the file systems, so it is replaced by an underscore.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Introduce io.element.android.libraries.mediaviewer.api.FileViewerEntryPoint, a
reusable screen which renders content that is not a Matrix media the same way the
media viewer renders a file, with Share and Download actions.
The caller provides a filename, a mime type and the whole content as a String.
The node writes it to a temporary file in the cache directory, then reuses
LocalMediaView (so text content goes through TextFileViewer) and LocalMediaActions
for sharing and saving on disk. The node is contributed to AppScope so that the
screen can be used from any graph, since MediaViewerNode itself is bound to
RoomScope and depends on the timeline data sources.
Also route MimeTypes.Json to TextFileView in LocalMediaView, so that a json file
is rendered as text instead of falling back to the generic file card.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Editing the caption of a media message dropped all of its formatting: bold,
links and the rest came back as plain text, and saving wrote that plain text
over the formatted caption.
The composer was being opened on the plain caption. Editing a message body
already starts from its HTML when rich text editing is on, and the caption
path was the only one that did not - it read `captionOrNull()` and never had
the caption's HTML to read, because the timeline content only kept the
already-parsed `formattedCaption`.
Media contents now carry the caption's HTML alongside the parsed one, the
same way text contents carry `htmlBody`, and editing a caption starts from it
when rich text editing is on. The save path already sent the composer's HTML,
so nothing changes there.
Part of #6730
Deleting a message that headed a thread took the thread with it: the "N
replies" summary under the message disappeared and there was no way back to
the replies, which are still there.
Every branch of the timeline content mapper passes `MsgLikeContent`'s thread
information on except the redacted one, which returned a bare
`RedactedContent` and dropped it. The thread summary lives on
`MsgLikeContent` next to `kind`, so it survives the redaction; only the app
was throwing it away. `RedactedContent` now carries the thread info like the
other contents do, and `EventTimelineItem.threadInfo()` reads it.
A deleted message that still heads a thread is also left out of the "N
removed messages" group, which would otherwise hide the summary again as soon
as three deletions ended up next to each other.
Part of #7397
Upgrading over an older install crashed before the login screen with
`SQLiteException: no such column: SessionData.position`. The session, cache
and push databases were opened at their new schema version but their tables
were never migrated.
`SqlCipherDriverFactory` overrides `AndroidSqliteDriver.Callback.onUpgrade` so
the database key can be replaced, and never called through to the base
implementation - which is the only thing that runs `schema.migrate`. Every
SQLDelight migration in the app was skipped as a result.
The override now calls `super.onUpgrade` after the re-key, so a database that
crosses the re-key version is still re-encrypted before its tables are
migrated. It moved out of an anonymous object into a named `MigrationCallback`
so the behaviour can be tested.
Part of #7509
The room list preview prefixes the sender's name unless the room is a
direct message. A room that was created as a group and later converted to
a direct message is not marked as one by the server, so its preview kept
naming the only other person in it on every message, while iOS did not.
The prefix now depends on how many people are actually in the room rather
than on the direct message flag, which is the behaviour asked for in the
issue: no name while only two people can be talking, the name back as
soon as a third joins.
Part of #1548
While the homeserver is unreachable but the device still has a working
network, the app showed no indication at all: the syncing chip is hidden
as soon as the SDK reports the session offline, and the offline banner
only appears when the device itself has no connectivity. A blocked or
down server was therefore indistinguishable from a quiet, healthy one.
The chip now has three states rather than a boolean, and the third says
"Server unreachable" for exactly that case. When the device has no
network the chip stays hidden, because the offline banner already says so
and two overlapping messages would be worse than one.
Part of #4099
renovate[bot]
Benoit Marty
hayaksi1
Benoit Marty
ElementBot