compose: Don't show compose box for private, unsubscribed channels

[chrisbobbe]

I noticed this while working on #1555.

Fixes #1651.

Before	After

[rajveermalviya]

Thanks @chrisbobbe! LGTM.

[gnprice]

Huh interesting. Is this the right logic?

You could be viewing a channel that's private, you're not subscribed, but you have content access to (now that that's a thing). In that case I'd expect the rule for whether you can post to be the same as it is for a public channel.

[chrisbobbe]

you have content access to (now that that's a thing)

Are you thinking of shared vs. protected history, or is there a newer feature than that that I'm not aware of?

[gnprice]

This one: https://zulip.com/help/configure-who-can-subscribe

This permission grants access to channel content: users who are allowed to subscribe to a channel will also be able to read messages in it without subscribing.

It looks like in order to send, one then has to actually subscribe:

A designer on the team could then follow a link to a conversation in the private engineering channel, and read it without subscribing. They could subscribe if they need to send a message there, without asking for help.

Seems like a wart that that's different from the behavior for public channels, though. And ISTR a recent chat thread where either Alya or Tim said that behavior for public channels was likely to change.

I think the upshot is:

• this logic should live somewhere more central, in model code; probably within the hasPostingPermission method (which in turn should ultimately be on ChannelStore, after other refactors);
• the public-vs-private quirk should get a comment pointing to the help page and/or to a relevant chat thread;
• let's finish taking care of search and some other priorities before returning to finish this 🙂

[alya]

zulip/zulip#21433 has some work by a current GSoC participant.

[gnprice]

(Propagated the milestone from the issue.)