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.

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?

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 🙂

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

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.

I think that note in the doc makes sense for frontend users, because frontend hasn't implemented sending at all when unsubscribed, even when you have permission: zulip/zulip#35902. (That issue supersedes the one Alya linked to here.)

I don't think the server actually prohibits sending to all unsubscribed private channels though. There's no note about that in the "Channel posting policy" Help Center doc; I read that doc as saying that can_send_message_group is the only thing that controls whether you can send messages in a channel.

As of #1863 being merged, we do now respect can_send_message_group, when present, so I think there's nothing more to do here and I'll close this.