I don't have a strong opinion on this solution. We can keep it, or modify the type to be an array when the robotext creation flag is irrelevant, or we can even consider introducing specs for relationship actions where we define whether robotext messages could be created. But overall, I don't think it is beneficial to spend too much time on it, so even abandoning it makes sense because it is unlikely to cause any trouble in the future.
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
Feed Advanced Search
Advanced Search
Advanced Search
Wed, Sep 25
Wed, Sep 25
Tue, Sep 24
Tue, Sep 24
tomek added inline comments to D13418: [lib] Set roles and permissions in thick threads based on parent permissions.
tomek updated the diff for D13418: [lib] Set roles and permissions in thick threads based on parent permissions.
Inherit permissions from the parent
tomek added inline comments to D13447: [lib] fix changing thread description on native for thick threads.
[native] Enable NUX
tomek added inline comments to D13438: [keyserver] Rework updateRelationships on keyserver to use new API.
Mon, Sep 23
Mon, Sep 23
tomek added a comment to D13418: [lib] Set roles and permissions in thick threads based on parent permissions.
I think adding these hacks to the permissions system is a really bad idea. The permissions system is already incredibly complex, and a huge cause of confusion / bugs / problems. If there's one place we should be thoughtful about technical debt, it's the permissions system
The permissions system for thick threads is completely isolated from keyserver threads. So I don't think introducing hacks here makes our permissions system introduce a tech debt that has significant interest rates. The thick thread system doesn't have any mechanisms like permissions inheritance, prefixes, etc. that caused bugs in the past. Introducing these would make the system a lot more complicated. So I think the current approach is better for now, and can be easily replaced in the future, but I'm going to scope the right solution to make sure how expensive it is - https://linear.app/comm/issue/ENG-9361/scope-the-right-solution-to-permissions-of-thick-sidebars.
tomek committed rCOMM359d8031d62d: [lib] Use `UPDATE_THREAD_READ_STATUS` update to update the read status (authored by tomek).
[lib] Use `UPDATE_THREAD_READ_STATUS` update to update the read status
tomek requested review of D13424: [lib] Use `UPDATE_THREAD_READ_STATUS` update to update the read status.
Fri, Sep 20
Fri, Sep 20
tomek committed rCOMM2d42431b4c86: [lib] Create a thin thread when some users don't support thick threads (authored by tomek).
[lib] Create a thin thread when some users don't support thick threads
tomek committed rCOMMb74fa444e9fb: [lib] Exclude users that don't support thick threads from results (authored by tomek).
[lib] Exclude users that don't support thick threads from results
[lib] Avoid unnecessary sets creation
tomek updated the diff for D13404: [lib] Create a thin thread when some users don't support thick threads.
Add a comment
tomek added inline comments to D13405: [lib] Exclude users that don't support thick threads from results.
tomek requested review of D13405: [lib] Exclude users that don't support thick threads from results.
tomek requested review of D13404: [lib] Create a thin thread when some users don't support thick threads.
I am also thinking about adding viewerID to ProcessDMOperationUtilities, as it seems like the right place to put it and could simplify it, curious also for @tomek's perspective.
tomek added inline comments to D13375: [lib] Take operations from the queue when conditions become met.
Thu, Sep 19
Thu, Sep 19
tomek committed rCOMMebe8eb9bd0db: [lib] Take operations from the queue when conditions become met (authored by tomek).
[lib] Take operations from the queue when conditions become met
tomek committed rCOMM25b472e3dbe5: [lib] Update the conditions we check before processing the operations (authored by tomek).
[lib] Update the conditions we check before processing the operations
tomek committed rCOMM72a2625fbbbe: [lib] Allow queueing based on new conditions (authored by tomek).
[lib] Allow queueing based on new conditions
[lib] Queue operations
[lib] Introduce new operation queues
Deduplicate
Improve performance
[lib] Disable editing failed messages
tomek requested changes to D13383: Fix DM activity handler not to send unnecessary read status update.
This solution feels a lot more complicated than it should. Maybe it has to be that complicated, with canceling and flushing, but I'm not sure.
Wed, Sep 18
Wed, Sep 18
tomek requested changes to D13385: [lib] remove `outboundP2PMessages` for devices removed from device list.
It might be a better idea to clear the messages when a device is removed from the device list.
tomek added inline comments to D13371: [lib] refactor `createOlmSessionWithPeer` -> `createOlmSessionsWithUser`.
tomek committed rCOMMab389ba6796c: [web] Remove admins tab when there are no admins (authored by tomek).
[web] Remove admins tab when there are no admins
tomek committed rCOMMa80f96b3c214: [lib] Allow reacting and creating sidebars from failed messages in thick threads (authored by tomek).
[lib] Allow reacting and creating sidebars from failed messages in thick threads
tomek updated the test plan for D13366: [lib] Update the conditions we check before processing the operations.
tomek updated the test plan for D13375: [lib] Take operations from the queue when conditions become met.
tomek updated the diff for D13366: [lib] Update the conditions we check before processing the operations.
Fix edit message condition
tomek updated the diff for D13366: [lib] Update the conditions we check before processing the operations.
Update reaction message condition
tomek updated the diff for D13362: [lib] Allow reacting and creating sidebars from failed messages in thick threads.
Delete logs
Tue, Sep 17
Tue, Sep 17
tomek requested review of D13366: [lib] Update the conditions we check before processing the operations.
tomek added inline comments to D13339: [lib] Update entry reducer so thick entry infos are properly stored.
In D13349#376126, @ashoat wrote:Where would we document? Maybe @tomek was thinking of something like a function function isCalendarEntryHistoryEnabled(threadType: ThreadType): boolean
Mon, Sep 16
Mon, Sep 16