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
Advanced Search
Wed, Sep 25
Tue, Sep 24
Inherit permissions from the parent
Mon, Sep 23
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.
Fri, Sep 20
Add a comment
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.
Thu, Sep 19
Deduplicate
Improve performance
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
It might be a better idea to clear the messages when a device is removed from the device list.
Fix edit message condition
Update reaction message condition
Delete logs
Tue, Sep 17
In D13349#376126, @ashoat wrote:Where would we document? Maybe @tomek was thinking of something like a function function isCalendarEntryHistoryEnabled(threadType: ThreadType): boolean