* grammar fix
* IEncryptionResult -> EncryptionResult
These are the same thing; the former is the old name.
* Support setting event IDs
* Helper for decrypting existing decryption failures
* Clean up README a little
This just removes some of the most egregious lies and outdated stuff. There's a
*lot* more that can be done here.
* Add some test utils in a new entrypoint
* Fix comment
* Update src/testing.ts
* Fix highlights from threads disappearing on new messages
This changes interface of Room, so this is a BREAKING CHANGE.
Correctly mirrors the logic we use for room notifications for thread
notifications, ie. set only the total notifications count from the
server if it's zero.
I'm not delighted with this since it ends up with function on room
whose contract is to do something frankly, deeply weird and
unintuitive. However, this is the hack we use for room notifications
and it, empirically, works well enough. To do better, we'd need much
more complex logic to overlay notification counts for decrypted messages.
Fixes https://github.com/element-hq/element-web/issues/25523
* Add tests for the special notification behaviour in syncing
* Correctly copy the room logic for reseting notifications
We were always ignoring the highlight count, even for encrypted rooms,
which was broken because we don't do the local calculation for unencrypted
rooms.
* Move code for processing our own receipts to Room
This is some code to process our own receipts and recalculate our
notification counts.
There was no reason for this to be in client. Room is still rather
large, but at least it makes somewhat more sense there.
Moving as a refactor before I start work on it.
* Add test for the client-side e2e notifications code
* Extend logic for local notification processing to threads
There's collection of logic for for processing receipts and recomputing
notifications for encrypted rooms, but we didn't do the same for threads.
As a reasult, when I tried pulling some of the logic over in
https://github.com/matrix-org/matrix-js-sdk/pull/4106
clearing notifications on threads just broke.
This extends the logic of reprocessing local notifications when a receipt
arrives to threads.
Based on https://github.com/matrix-org/matrix-js-sdk/pull/4109
* simplify object literal
* Add tests & null guard
* Remove unused imports
* Add another skipped test
* Unused import
* enable tests
* Fix thread support nightmare
* Try this way
* Unused import
* Comment the bear trap
* expand comment
* Move code for processing our own receipts to Room
This is some code to process our own receipts and recalculate our
notification counts.
There was no reason for this to be in client. Room is still rather
large, but at least it makes somewhat more sense there.
Moving as a refactor before I start work on it.
* Add test for the client-side e2e notifications code
* simplify object literal
* WIP fix for bugs first-thread-reply bugs
* Add re-emitter before we start adding events, as per comment
* Add test for notification bug
* Test for the bug that caused the dot to be the wrong colour
* Add comment
* elaborate
* Fix outdated comment
* Also fix this comment
* Fix another comment
* Fix typo
Co-authored-by: Richard van der Hoff <1389908+richvdh@users.noreply.github.com>
* Clarify comment
* More comment
* so much comment
also reformat (the bit that's actually added is s/it/this.addEvents/)
* The comments
* Maybe make comment clearer.
* Add comment about potential race
---------
Co-authored-by: Richard van der Hoff <1389908+richvdh@users.noreply.github.com>
* Introduce Membership TS type
* Adapt the Membership TS type to be an enum
* Add docstrings for KnownMembership and Membership
* Move Membership types into a separate file, exported from types.ts
---------
Co-authored-by: Stanislav Demydiuk <s.demydiuk@gmail.com>
* fix automatic DM avatar with functional members
* update comments
* lint
* add tests for functional members
* keep functional members out of the public API
- remove public API for functional members, reverting most of 0ce2d82, f9b41f6, e65fb24
- remove tests for functional members public API c114bf5
- add shared functional members getter for both room name and avatar fallback generation
* filter functional members from more candidates
- remove from hero(es)
- remove from previous members
* add tests for fallback avatars with functional members
* Add docstring for getFunctionalMembers
Co-authored-by: Richard van der Hoff <1389908+richvdh@users.noreply.github.com>
* inline getInvitedAndJoinedFunctionalMemberCount
* update comments for getAvatarFallbackMember
* use correct list of heroes in getAvatarFallbackMember
* remove redundant type annotation
* optimize performance of invitedAndJoinedFunctionalMemberCount
* calculate nonFunctionalMemberCount in one step
instead of iterating redundantly
* clean up functional member tests with review feedback
* lint
* Update src/models/room.ts
Co-authored-by: Richard van der Hoff <1389908+richvdh@users.noreply.github.com>
* apply feedback about comments
* non-functional per review, lint
---------
Co-authored-by: Richard van der Hoff <1389908+richvdh@users.noreply.github.com>
* Export types describing all specced media event formats
Signed-off-by: Michael Telatynski <7t3chguy@gmail.com>
* Iterate PR
Signed-off-by: Michael Telatynski <7t3chguy@gmail.com>
* Move types to a dedicated export
Signed-off-by: Michael Telatynski <7t3chguy@gmail.com>
* Iterate
Signed-off-by: Michael Telatynski <7t3chguy@gmail.com>
* Add readme entry
Signed-off-by: Michael Telatynski <7t3chguy@gmail.com>
---------
Signed-off-by: Michael Telatynski <7t3chguy@gmail.com>
The root event of a thread used to arrive with the pagination request, but this was unspecced and so got changed to simply fetch the root event. In many (almost all) cases this shouldn't be necessary because the thread should already have its root event: re-use it if it's already there. This is only in pagination, so there's no reason to believe that the root event would have changed and needs to be re-fetched.
This removes a number of duplicate calls to the /event/ endpoint from the tests.
