Display reply restrictions on tweet

[schmittlauch]

Since a while, Twitter allows restricting who can reply to a tweet. The 2 more restrictive settings are Only people I [the tweet author] follows and Only accounts mentioned in the tweet.
Unfortunately, these restrictions are not visually reflected so far in Cawbird. If such a restriction prevents you from posting, at least the error message popup you get when attempting to submit a reply post tells what is going on. But if this restriction is somehow reflected in the API data, it'd be preferrable to know about not being able to reply before taking the time to phrase a reply, click send, and only then find out.

Describe the solution you'd like
Each post shall display an additional logo or text hint in case any reply restrictions are active for the post. I am uncertain whether that shall be the case already for the timeline overview of posts or only in the details view.
Additionally, the reply button shall change its active state depending on whether the user falls into the permitted group under the specified reply restrictions or not. This shall happen for all views/ layouts, wherever such a reply button can appear.

Describe alternatives you've considered
If this information cannot be extracted from the API, then that is the way it is. I'd reject any brittle workaround like web scraping to overcome that restriction.

[IBBoard]

Yeah, I'd love to have this in. But I'm fairly sure this isn't possible in the v1 API. Hopefully they'll add it in v2.

[Edit] There's a reply_settings property in v2 Tweet objects but nothing equivalent in v1 Tweet objects

[CodedOre]

Yes, this is something we can (and should) get into the Twitter Platform on the new Backend.

It isn't yet included though. I as of now plan to add it to PostFlag, which is not implement yet.

Given it is a NewCaw-ToDo, would it make sense to move this issue to the NewCaw repository?

[IBBoard]

Everything that's tagged libhandy redesign was something that I'm not planning until NewCaw 🙂 They're all tickets that are dependent on the v2 API, a significant UI improvement, or some messy bit of the code that it'd be easier to rewrite rather than patch up.