Thanks much!
Last night, I implemented and have passing tests all through the stack (though I haven’t yet tested live) my first two ACs, but not yet the transcript flow, using a custom field on Topic and a thread rule. So making good progress toward being able to show code in at least a draft PR.
I also have a separate commit to remove the unused pstore_get from the slack provider. Since that’s the only use of pstore in the whole stack, would you like me to also remove all the pstore_* from app/initializers/discourse_chat.rb in that cleanup commit?
That’s exactly where I started, and it sure would have been easier!
However, at least for my use case (and I’ve heard this from people at other companies, we’re not unique) different channels have different preferences for whether threads should be used. There are channels which are meant to be used with threads (because most people care only about some topics) and channels which are very much anti-thread (because threads bury important information).
I’ve seen two essentially unrelated aspects driving this preference:
- Membership: Channels with most members having actively used IRC for decades are used to mentally disambiguating intermingled conversational threads in a single channel and don’t want to click into threads to see important content, whereas channels with most members having lived in email expect conversations to be threaded and to click into conversations they care about.
- Purpose: Channels with an announcement business purpose tend to be aggressively threaded, but channels with research or collaboration purposes are often intentionally not threaded because threads hide information unless you notice them and click into them.
If you’d like to have some common syntax for rule options, I’d think that Rule could be generally expanded so that it has an :options value which, like :tags, is an array. I suppose it might make sense to take a page from command-line shells, so that /discourse [watch|follow|mute] -something -here sets :options to ['something', 'here'] — reserving a leading - to introduce an option. Then it would be /discourse watch my-category-slug #tagged-foo -threaded. I don’t know how much more work that would be over what I already did. Do you have strong feelings one way or the other here? I can see arguments both ways: adding another value to Rule makes it more complicated to write a chat provider; adding another filter value makes another slack-specific feature (like posting a transcript) that makes the interface more complicated for non-slack users. Of course I might be missing something that would make it harder than I think; for example, if a category slug could start with - and it is suddenly ambiguous; the shell uses -- to mean “everything after this is not an argument” but perhaps we could invert it to -- means “everything after this is an option.” If you’d like me to look into this, please give me some direction on syntax that you would find appropriate for specifying rule options. But just adding thread seems simpler to me, so absent specific direction to add a general “options” feature, I’ll wait to make any change in that direction.
[Edit: Changing from a rule filter to an option would definitely complicate the UI which would have to grow to general support for general options and that doesn’t feel like a great choice to me. So now, having looked at UI, I’d prefer to stick with the filter; I think it’s cleaner.]
For the post transcript flow, thanks for the HTML comment idea. For my use case it’s not going to hurt me any; I’m honestly expecting to be the primary user anyway, at least initially. That’s a nice simple hack.
I have a separate idea, not to embed in this PR, that it would be nice to have a mapping from the channel for the message being posted to the category in which the resulting discourse post should be made. For that to happen, I think that the transcript would best change to have an envelope or sidecar, at which point the envelope or sidecar could have both the category and the slack ID. That looks like a substantial amount of learning for me, since I’m still in the “advanced googling the problem” stage of learning Ruby on Rails. 
