Purpose of 'is_private' in Private Discussions Posts

Mallinger

As far as I understand, the is_private field in the discussions table prevents private discussions from becoming public even if the Byobu extension, for whatever reason, stops working.

The posts table also has an is_private field and I don't understand its meaning. The posts in my database with an is_private value of 1 are posts created with Byobu during beta versions of Flarum, mostly the first 1-2 posts in a discussion. After updating to Flarum 1.6 these posts are not shown anymore, even within the corresponding private discussions. Once I set is_private to 0 they show up again.

What's the purpose of this field in the posts table and can I safely set them all to 0?

clarkwinkelmann

It's just the way the Flarum visibility API is designed.

Extensions have 2 choices: set things to visible by default and add SQL conditions to exclude things, or set things to hidden by default and add SQL conditions to make them visible. As you correctly suggest, the goal is to avoid content becoming public if the extension is disabled or encounters an error.

Posts are a bit more complex than discussions because part of the SQL query checks if the user can see the discussion, so is impacted by both constraints.

At some point during the beta there was only one of the 2 that had is_private, and I remember the second one was added to Flarum specifically to make this easier and safer in Byobu. I'm not sure which one it was and in which beta though.

Looking at Byobu source code, it seems to be only using the Discussion private API, and doesn't touch the one for posts.

Maybe it's a leftover from a very old version? In this case you should indeed set is_private to 0 on posts.

The posts private API is used by other extensions and maybe it's those extensions that are interfering with Byobu. The Approval and First Post Approval extensions for example will set the flag, and remove it after the content has been approved. I'm not sure how it interacts with private discussions by Byobu.

Mallinger

clarkwinkelmann Looking at Byobu source code, it seems to be only using the Discussion private API, and doesn't touch the one for posts.

This makes sense, as I don't currently see a use case for Byobu to publish single private posts in an otherwise public discussion.

clarkwinkelmann The posts private API is used by other extensions and maybe it's those extensions that are interfering with Byobu.

I understand, and I really hope future extension developers understand, that they cannot rely solely on the is_private field to determine whether or not a post should be considered private.

The question remains wether Byobu should simply ignore the is_private field in posts to avoid these problemes or set the is_private values in the posts table to 0 during migration.

luceos

Mallinger The question remains wether Byobu should simply ignore the is_private field in posts to avoid these problemes or set the is_private values in the posts table to 0 during migration.

I think that setting is_private on Posts happened only in one of the Flagrow versions while Flarum was in beta. Only is_private on discussions is now used to mark a discussion as private. You can safely update all posts to have 0 in is_private as long as you keep the discussions from Byobu intact with is_private 1.

The original issue that caused us to implement is_private can be found here: FriendsOfFlarum/byobu11. The reason it was introduced was indeed to prevent private discussions from leaking to the public once the extension was disabled or uninstalled. is_private works by marking a discussion or post as invisible by default, but any extension can use backend (php) logic to authorize access to any of these based on the user.

clarkwinkelmann

Mallinger that they cannot rely solely on the is_private field to determine whether or not a post should be considered private

Just to comment on this, extensions definitely should not and technically can't really use is_private as a source of truth. is_private is a value that's dynamically set based on conditions set by the extension to toggle the SQL query structure. The SQL query itself will be built based on specific attributes like approved_at for Approval and the recipients table for Byobu.

I looked through Byobu migrations but I can't really find what/where something went wrong with the change from posts to discussion private API. Maybe we had a migration to clear out the posts state but it got lost to history. Or a change to Flarum's internals caused the posts to behave differently which exposed the leftover flags which previously didn't have an impact (?) At this point in time there will hopefully be very few outdated installs still in production so it's good enough if we can help with this manually. We're quite lucky to still have most original extension developers (and their extensions!) around.

Mallinger

luceos The original issue that caused us to implement is_private can be found here: FriendsOfFlarum/byobu#11 (comment).

The reasoning becomes clearer to me. is_private is not really a Byobu thing, even if Byobu was the reason to implement it. is_private is a mechanism of Flarum's core open to any extension that wants to hide posts or discussions from the general public, and then decides for itself under what circumstances it wants to show the content. So if a post or topic is deemed private by any extension, for safety reasons it should remain hidden even if said extension stops working.

Byobu has used this feature at the post level for a while, but now it manages is_private only for discussions. So Byobu no longer takes care of is_private for posts, which means that Byobu does not tell the core in any way what to do with those posts. Therefore, these posts are hidden by the Flarum core because is_private is set to 1 and the core is not told by any extension to display them anyway.