[PAID] Thread based privacy control

[Kolya]

When starting a thread the user can select which other forum members will be able to see it.
Of course there should also be a "public" option (default) and admins & moderators would be able to override these controls.

For: SMF 2.0.1

Extra points for being able to select membergroups and "my buddies".

[Kolya]

I updated this to a paid request. I'm thinking of 50€ (around 70$ US) here, payable via Paypal. I know it's not much but I'm asking on behalf of a non-profit fan-site (http://www.systemshock.org).

I would want the modification code to be GPL'ed. So while I'll pay for it, the modification should be offered here for free for everyone else, so it can be used and improved by anyone.

[emanuele]

Do you want to have permissions to define who will be able to select a "privacy" restriction?
The topics should be visible on message index only to the allowed membergroups? Or should be visible to everybody?
What about post based groups?
BSD would be fine?

[Kolya]

Do you want to have permissions to define who will be able to select a "privacy" restriction?

Only in the sense that guests should only be able to create public topics, because otherwise they couldn't see their own topics. But every member should be allowed to select privacy restrictions. So I don't need a permission for that.

The topics should be visible on message index only to the allowed membergroups? Or should be visible to everybody?

To someone who is not in the list of allowed viewers they should behave exactly like a topic in an inaccessible board. So they would be invisible everywhere to that person, incl. recent topics list, rss, etc.
I think this is in line with SMF's general principle of hiding inaccessible content and functions.

What about post based groups?

I guess that would be useful for others, but I don't need post count based groups to be selectable.

BSD would be fine?

Actually I would prefer a copyleft or sharealike license to ensures that derivative works (eg versions improved by others) will also be free. Is there a special reason why you suggest BSD?

[Sorck]

Just a few ideas of the top of my head - feel free to use the ideas in my post:
Is the sort of selector you're looking for similar to the SMF PM user selector? Where once you've typed a few letters in suggests a few of members with the typed string in their name.

That would serve as an example for per-user privacy and public "privacy" could be a checkbox? I can see buddy-level privacy but it would only be feasible for current buddies IMO.

Also, there are a lot of places where this privacy setting would need to be checked:
Unread Posts (?action=unread)
Unread Replies (?action=unreadreplies)
BoardIndex.php latest post
MessageIndex.php posts and child board latest posts (?board=)
SSI.php recent posts/topics
Display.php (?topic=)

Might have missed a few in that list.

With regards to permissions you may need to check whether or not to let people specify non-public options; edit their topics privacy; edit others topics privacy; see topics regardless of privacy settings - you might want your moderators to see topics regardless of privacy settings but you might not want your moderators to see "private" topics.

BSD would be fine?

Actually I would prefer a copyleft or sharealike license to ensures that derivative works (eg versions improved by others) will also be free. Is there a special reason why you suggest BSD?

If you interpret the GPL strictly then it cannot share memory with other-licensed code such as the BSD licensed SMF2 and hence in the strictest following of the GPL you can't use a GPL mod for SMF at all.
The GPL is actually quite viral in its nature (put GPL code in your codebase and you're forced to make it all GPL licensed).

BSD code can be included in a commercial/closed source project but the BSD licenses must remain in place IIRC and the original code will still be available.

[Kolya]

Is the sort of selector you're looking for similar to the SMF PM user selector? Where once you've typed a few letters in suggests a few of members with the typed string in their name.
That would serve as an example for per-user privacy and public "privacy" could be a checkbox?

Yes.

I can see buddy-level privacy but it would only be feasible for current buddies IMO.

I'm not sure what "current" means in this context.

Also, there are a lot of places where this privacy setting would need to be checked:...

If at all possible the check would be integrated with the existing accessibility checks. I'll rather have a smart hack than a thorough solution that breaks with the next SMF update.

With regards to permissions you may need to [1.] check whether or not to let people specify non-public options; [2.] edit their topics privacy; [3.] edit others topics privacy; [4.] see topics regardless of privacy settings - you might want your moderators to see topics regardless of privacy settings [5.] but you might not want your moderators to see "private" topics.

1. All members can set privacy restrictions, guests cannot. This can be hardcoded.
2. & 3. Would certainly be nice, but might be left up for the next version.
4. & 5. Admins and moderators can see all topics. Hardcoded is fine.

GPL is a virus, etc

I would rather not go into a license discussion here, unless you plan to write this mod.
Suffice to say that you can of course use a GPL mod with SMF.

[emanuele]

Sorry if I didn't say anything for a while, my computer broke a while ago and I'm still trying to organize with what I have...

Just a note: I was already considering this mod before you posted the [paid] (I just forgot it for a while...), so I'm not doing it for the money. (and I don't want it )

At the moment I can't give you a date for when I'll provide something...sorry.
If someone else wants to do it, please feel free!

The topics should be visible on message index only to the allowed membergroups? Or should be visible to everybody?

To someone who is not in the list of allowed viewers they should behave exactly like a topic in an inaccessible board. So they would be invisible everywhere to that person, incl. recent topics list, rss, etc.
I think this is in line with SMF's general principle of hiding inaccessible content and functions.

Then I'll implement it only for membergroups, unless someone can clear my doubts about performance of a similar solution: I already think it's not so light check permissions at group level for each topic, but I have the feeling that permissions at user level would be quite heavy to handle for a server.

BSD would be fine?

Actually I would prefer a copyleft or sharealike license to ensures that derivative works (eg versions improved by others) will also be free. Is there a special reason why you suggest BSD?

1st because I'm licensing all my mods that way, so in the remote case any of them would be useful it could be integrated into SMF without any kind of problem, 2nd because I don't care about license stuff and for that reason the implications of GPL are too complicated to understand for me and (most important) 3rd I don't like to tell others what they have to do with their own work, so if they want to share fine, otherwise they can do what they want, I'll do my best to do it better!


Just to clarify:

If you interpret the GPL strictly then it cannot share memory with other-licensed code such as the BSD licensed SMF2 and hence in the strictest following of the GPL you can't use a GPL mod for SMF at all.

That's completely wrong.
1st license is related to distribution of the software, not to its usage.
2nd if you want to be strict: SMF is BSD, so it can also be redistributed as GPL.

[Kolya]

Hey emanuele.
Glad to see that you're still interested in this (and had been all along as it turns out).
Take your time, I'm not in a hurry with this one.

An inspiration for it is the way Google+ handles privacy of their posts. They manage to do it on the user level, with whatever magical software they use. I guess you're right and it would take a lot of resources to check permissions for every single thread in PHP/SMF. But let's not kick this idea out yet, because fine control of what you share with who is the whole point.

The largest part of threads being viewed will always be public ones. That's because of guests viewing the boards and because public threads will receive more answers, so users will be inclined to make threads public if there's no reason against it.
So we'd have a huge number of pageviews that check this large amount of public threads for privacy permissions. Couldn't we do away with this? What if "public" was just assumed to be default and this privacy setting was opt-in instead?

We would just show every thread unless that thread specifically says: "Um guys, you can't just show me around to anyone, I got some privacy settings here. Please have a look at them first."
So the thread would trigger that privacy check, instead of SMF checking every single thread.

[Sorck]

I've had a few thoughts on how this could be achieved (including "My Buddies" as an option )

Efficiency
a) only run queries for those who need them - no point checking for privacy if you're an admin
b) only check if it's possible for you to see the topic - if you're a guest then there's no point checking buddies or if you've been selected as a specific person who can see it
c) order the queries based upon the likelyhood of them being selected as a privacy option - public, my topic, buddies, friends

I foresee the need for 3 columns added onto smf_messages (or smf_topics):
privacy_public (default 1 means that anyone can see the topic, 0 means that other restrictions are in place)
privacy_buddies (default 1 means that the posters buddies can see the topic)
privacy_users (a comma delimited list with the ID's of specific users who are allowed to see the topic)

Public checking would be easy

Koodi [Valitse] Laajenna

WHERE t.privacy_public = 1
Adding in user level privacy...

Koodi [Valitse] Laajenna

WHERE (
t.privacy_public = 1
OR FIND_IN_SET({int:id_member}, t.privacy_users)
)

I had a look into how buddies are stored and it wouldn't be much of an impact if you did search for them - just a single extra JOIN to the members table. The following assumes that the members table is aliased as "mem"

Koodi [Valitse] Laajenna

WHERE (
t.privacy_public = 1
OR t.id_member = {int:id_member}
OR t.id_member = 0
OR FIND_IN_SET({int:id_member}, t.privacy_users)
OR FIND_IN_SET({int:id_member}, mem.buddy_list
)

How it works is that it does the checks in order so for most threads (which will likely be public) it will miss most of that where clause (it only need check if privacy_public = 1) so only one check would be made unless the thread wasn't set as public.


Are there any other possible privacy settings beyond public, buddies and specific user?
I'm not sure how you'd go about membergroup checking as that would require seeing if any id from your personal group list is in the topics "group privacy" list. Might be possible but I'm sure that it would take quite a few extra "blah LIKE this" statements.

[Kolya]

For a reasonable membergroups check you'd also have to test if the threadstarter himself is in that group. But as I said membergroups (and buddies) would be a bonus, as long as you can select individual members.

[emanuele]

Sorry for the long silence.
Unfortunately I'm having few problems and I had to stop many things.

I don't know if I will be able to finish it, I still hope to be able to provide something, but if anyone else wants to work on it feel free!