Wedge

I have this horrible feeling that I won't get an answer anytime soon to this long post, so let's just make it simple...
Long ago I decided to add 'custom membergroups' to Noisen. I implemented it. Then I removed it and ended up using UltimateProfile's custom buddy lists.

When we made Wedge, we discussed adding custom membergroups. Then the idea was abandoned, too.

I just don't remember WHY I gave up on these the last two times, when it seems like the 'cleanest' way of implementing user relationships on a website... (Having multiple relationship types, like groups and contacts, is just inefficient IMHO when we could simply merge both table types.)

Does anyone remember reading a conversation around here about membergroups...?

A single error on my side, and people are going to think we're clowns :P

I'm afraid I don't remember... :lol:

It's all in AeMe. I'm sure we can cook up a version that works outside of it. (Well, technically it does, for picture embeds. I just don't remember where I'm doing the add_js stuff, ahah...)

No, seriously, Zoomedia was a nightmare to develop. It was done faster than many of the 'nightmares' I worked on, but it was enough of a hassle to encourage me to just leave it be instead of working on adding support for slideshows and video embedding.

You talkin' to me? I'm... not... Pete.
I'm the French one. Y'know, the b'stard.

Anyway, yeah of course the demo site could be online by the hour...
Actually, all of you members of the Friends group have been playing with various demo sites of Wedge for over a year so you know it's usable... ;) It's just that once we start using Wedge here, we'll have to upgrade the site regularly and I already have a hard time doing it for my local install... :P

You have no idea how unnerving it can be, at least when it comes to Wedge...
Just because we decided we'd go for a separate demo site until we stabilize the database enough to warrant easy upgrades for Wedge.org, doesn't mean it's not easy to install on a demo site... Have to think of things like copying the badge images manually, replacing bareimg to img in the signatures, rewriting the homepage to add direct links to alternate skins for guests and things like that... Oh my...

Ah, yes... But you don't know me -- 'by' March 15, to me, means, "HOPEFULLY on March 15", because I also do important things at the last moment :P (Go ask my tax collector!)

They only disappear when there's only one language in the languages folder.
Wedge should logically ship with only the English language files, so with all flags disabled... I don't want to burden every single English website with a French version they don't give a damn about :P

No, it was just an example... I don't think Recent items are in danger of being seen.
But we'll definitely need to audit most of the queries.

I think I'll do it like I did on Noisen.com back when I implemented the feature... I'll create a few topics, add a hidden word in them, set privacy to myself on them, and tell everyone that if they ever find the word, they should contact me immediately and I'll reward them for helping protecting the website's security settings.
It'll only be made more important by the fact that people are really gonna use these privacy settings...

Oh, while I'm at it.
I'm still working on database structure, getting close to the end thankfully. The major change these last few days, is that I decided that if topic privacy is going to be so specific ("member 34 and group 12..."), that it would only make sense to use the same feature on board access. We'll need to keep in touch to make sure it doesn't conflict with board access/view permissions, obviously... (I'm thinking board privacy should be tested first, and then these permissions. Does Wedge do a {query_see_board} BEFORE the permissions are tested? In which case it should be fine.)

Now, my main concern is with the has_privacy field. It's a tinyint(1) field (i.e. bool), so it won't take any significant space in the DB, but I'm not sure that the field will be taken into account by the key selection system in MySQL...
For performance reasons, I *suppose* it's best to do the test for that bit as late as possible in the process...? i.e. if its index isn't used, might as well execute the test last, so that it doesn't waste time doing a filesort or something on the table? (Yeah, after all these years I'm still THAT bad at MySQL optimization...)
In which case it'd mean we have to move all query_see_board tests to the end of all queries. I don't know.
Now, the boards table has a member_groups key, all alone by itself, so maybe it's really not a problem and our has_privacy field will not make it slower... (Assuming that the board table has thousands of entries, which is ridiculous normally, but not when you add a feature to allow people to create their own blogs. Will do... Later.)

Anyway...
So, if has_privacy = 0, there's nothing else to do. If has_privacy = 1, we join the privacy_boards table (I've switched the two words so that all privacy boards are next to each other, easier debugging), and we test for availability.

Also, Noisen's topic privacy feature has a 'default' which uses its parent board privacy settings. (IIRC it'll always use the parent board's privacy and then apply its own on top.) I'm assuming that all 'sensitive' topic queries in SMF/Wedge already do a query_see_board on them, so it shouldn't be a problem, but what if it is...? We don't want to show, in a list of topics, some topic that has no privacy settings but is in a board that shouldn't be viewed... But I suppose this privacy issue would have been spotted first, right..?
Obviously we'd have to remove the member_groups field from wedge_boards and have TE include some code to import these entries into the privacy_boards table. Shouldn't be a problem...

NB: board privacy is not yet included, only did the table in the sql file, I just want to discuss it and make sure it's the right direction... But I somehow suspect that if people are gonna be able to create their own boards (once we had a permission for them to do so), they'll be *thrilled* to know that they can fine-tune who gets to see them.
Noisen has such a feature already, but if I'm going to write a complex JavaScript UI for maintaining privacy lists, might as well use it everywhere...

NB2: Okay, I looked into board access... Oh my.
Wedge adds the ability to choose whether a group can KNOW (view) about a board, can ACCESS or board, and can be prevented from knowing or accessing a board regardless of other group memberships.
That is very fine, but if the board is created by a user who wants to prevent someone they dislike from viewing it, they won't be able to do it because they can't create membergroups... Unless we allow them to do just that (which would also make topic privacy and thought privacy simpler to manage, let's just say...)

Maybe I'm "in the wrong". Maybe our "contact lists" should be membergroups and so on. Maybe we need to silently create a membergroup that contains just users 5 and 47 if topic creator requests that only users 5 and 47 can read it. (And remove the membergroup if they change privacy settings for that topic and no other privacy area uses that group.)
I don't know...

Oh my. It's never going to end, is it...?Then it's a bit surprising that m.approved tests being done at the end of a query still gather attention from big board owners...
(Or they really need to buy huge equipment and not bother. I don't know how Facebook does it...)So, not digesting well... :PWedge just isn't fun to work on when it requires going through the entire codebase and rewiring everything...

I'm just a bit sad that I have so much desire for user freedom when writing privacy settings, and that it suddenly seems so unrealistic a goal to achieve with regards to database performance...