So... Hopefully I'll get some feedback on this. If not, at least writing my thoughts helps me sort them out a little.
Currently, Wedge does privacy[1] by storing data in different places. Profile privacy is stored in the profile owner's member data field (which is the perfect place for it, unless you start wanting to access this data from a place where ALL profile fields are requested, thankfully there aren't many), and topic privacy is stored in a field in the topics table, which is pretty much the opposite way of doing it: it's made with, in the mind, the idea that places that query multiple topics will want to access it, but nothing more, that is, you lose flexibility in favor of speed because you can't store multiple groups or lists or member IDs or whatever in it.
Now, a *privacy table* is something I left aside for as long as I could, because it forces me to:
(1) do a table join pretty much everywhere (okay, I can do a subselect from within {query_see_topic}[2], but I don't know if it'll hurt overall performance),
(2) insert a 'dummy' entry for each and every topic, including existing ones (which can be done through the upgrade script), meaning there'll be lots of useless data, i.e. id_group = 0 on the large majority of entries, possibly causing the same kind of performance problems that SMF has been having on large boards with the 'approved' bit. Meh...
But there are also other advantages:
(1) it can easily be extended by plugins (so that they can have their own privacy settings without the need for a new privacy table),
(2) speed could be better than any other solution, provided we cook up the 'perfect' system, and I'm afraid I alone can't build a proper efficient table,
(3) multiple privacy entries for everyone and everything,
(4) and it's cleaner.
So, I'm looking into preparing for that, and asking for feedback, suggestions, and alternatives I might have not thought about.
This is the preliminary, simplified privacy table structure I'm currently looking into.
wedge_privacy {
int: privacy_type (could be profile, topic, media album, etc.)
int: id_context (could be a topic ID, or a profile area like 'age', turned into a number...)
int: id_member (member ID of the owner -- useful for profiles)
int: id_target_member (member ID of someone who's given specific access to this, otherwise empty)
signed int: id_group (could be: 0 for everyone, 1 for members, 99 for just the author, 100+ for a contact list ID, -1 and below for a membergroup)
anything else..?
}
Maybe I should split privacy tables into two: one for topics, and one for all the rest... That way, the topic table wouldn't hurt performance for other privacy items.
Or, I could skip the whole 'have to have an entry for each topic', and add a flag to the topic table, saying whether it's a public topic (no privacy entry), or a topic referred to in the privacy table. I can't have it directly refer to a privacy table entry, as that would prevent me from adding multiple groups or lists for the topic.
Or if it's too complicated for you, just feel free to chip in regarding how you'd like me to deal with privacy on a user's point of view. For instance, do you like the idea that you can have multiple lists per privacy item (something I didn't even consider when I first built the feature, because I figured one could simply build a new list out of people you want to include from other lists, but then it can get crowded quick...), or individual member IDs per item (a feature that's actually already in Aeva Media, so I'll have to rewrite/force it into the new privacy system, but at least it's something you'll be familiar with).
In fact, I noticed this week (because I was looking into privacy settings for posting pictures of my kid) that Facebook (recently?) added a 'Custom' privacy setting which is really, really not all that obvious to the eye, but that pretty much allows you to do everything I'm planning to have... It doesn't have "Members" though (i.e. the ability to determine whether unlogged guests can see something), but it has "Friends of friends", which is something I'm not sure I want to have in Wedge... Well, you know, things like that, I'm all for your feedback, guys!
Currently, Wedge does privacy[1] by storing data in different places. Profile privacy is stored in the profile owner's member data field (which is the perfect place for it, unless you start wanting to access this data from a place where ALL profile fields are requested, thankfully there aren't many), and topic privacy is stored in a field in the topics table, which is pretty much the opposite way of doing it: it's made with, in the mind, the idea that places that query multiple topics will want to access it, but nothing more, that is, you lose flexibility in favor of speed because you can't store multiple groups or lists or member IDs or whatever in it.
Now, a *privacy table* is something I left aside for as long as I could, because it forces me to:
(1) do a table join pretty much everywhere (okay, I can do a subselect from within {query_see_topic}[2], but I don't know if it'll hurt overall performance),
(2) insert a 'dummy' entry for each and every topic, including existing ones (which can be done through the upgrade script), meaning there'll be lots of useless data, i.e. id_group = 0 on the large majority of entries, possibly causing the same kind of performance problems that SMF has been having on large boards with the 'approved' bit. Meh...
But there are also other advantages:
(1) it can easily be extended by plugins (so that they can have their own privacy settings without the need for a new privacy table),
(2) speed could be better than any other solution, provided we cook up the 'perfect' system, and I'm afraid I alone can't build a proper efficient table,
(3) multiple privacy entries for everyone and everything,
(4) and it's cleaner.
So, I'm looking into preparing for that, and asking for feedback, suggestions, and alternatives I might have not thought about.
This is the preliminary, simplified privacy table structure I'm currently looking into.
wedge_privacy {
int: privacy_type (could be profile, topic, media album, etc.)
int: id_context (could be a topic ID, or a profile area like 'age', turned into a number...)
int: id_member (member ID of the owner -- useful for profiles)
int: id_target_member (member ID of someone who's given specific access to this, otherwise empty)
signed int: id_group (could be: 0 for everyone, 1 for members, 99 for just the author, 100+ for a contact list ID, -1 and below for a membergroup)
anything else..?
}
Maybe I should split privacy tables into two: one for topics, and one for all the rest... That way, the topic table wouldn't hurt performance for other privacy items.
Or, I could skip the whole 'have to have an entry for each topic', and add a flag to the topic table, saying whether it's a public topic (no privacy entry), or a topic referred to in the privacy table. I can't have it directly refer to a privacy table entry, as that would prevent me from adding multiple groups or lists for the topic.
Or if it's too complicated for you, just feel free to chip in regarding how you'd like me to deal with privacy on a user's point of view. For instance, do you like the idea that you can have multiple lists per privacy item (something I didn't even consider when I first built the feature, because I figured one could simply build a new list out of people you want to include from other lists, but then it can get crowded quick...), or individual member IDs per item (a feature that's actually already in Aeva Media, so I'll have to rewrite/force it into the new privacy system, but at least it's something you'll be familiar with).
In fact, I noticed this week (because I was looking into privacy settings for posting pictures of my kid) that Facebook (recently?) added a 'Custom' privacy setting which is really, really not all that obvious to the eye, but that pretty much allows you to do everything I'm planning to have... It doesn't have "Members" though (i.e. the ability to determine whether unlogged guests can see something), but it has "Friends of friends", which is something I'm not sure I want to have in Wedge... Well, you know, things like that, I'm all for your feedback, guys!
1. | And the simple fact that it's the ONLY forum system to do it AFAIK is quite upsetting! Although it's also one of these 'killer' features in the killer app that is Wedge, so it's both upsetting and reassuring for me. :lol: |
2. | Thus something like SELECT id_topic FROM wedge_topics AS t WHERE ... AND (SELECT ... FROM wedge_privacy AS wp WHERE t.id_topic = wp.id_topic AND wp.privacy_type = PRIVACY_TYPE_TOPIC AND ((wp.id_target_member = {int:me} OR wp.id_group IN {array_int:my_lists_and_groups})... That looks VERY bad to me! |