« The Regular Members group
Privacy options
Image resizing for non-uploads »
Poll

Would you like to have topic privacy options in Wedge?

Yes -- everyone, just logged in users, and just the author.
4 (14.8%)
Yes -- everyone, just logged in users, just the author, and author's buddies (the regular SMF feature), even if it hurts performance a bit.
2 (7.4%)
Yes -- everyone, just logged in users, just the author, and author's contact lists (like buddies, but you can create multiple lists and put people in one or more of them), even if it hurts performance a bit.
16 (59.3%)
Yes -- everyone, or just me (i.e. just the ability to write drafts...)
0 (0%)
Yes, but I don't really care, I would never enable the feature on my forum.
1 (3.7%)
No, I don't care, and my users wouldn't either.
4 (14.8%)
Total Members Voted: 23

AngelinaBelle

  • Still thinking...
  • Posts: 92
Re: Privacy options
« Reply #30, on December 6th, 2011, 09:34 PM »
It will be complicated.
And scary, because you need to allow "everyone" to use stuff that was meant for only admin.
Easy enough to make the user moderator of the user's membergroups. New to make them able to create usergroups.
New and confusing to give them a simple new UI, then putting that output into creating an actual permission profile.
And new to let them apply a permission profile to a topic, a thing that doesn't have permission profiles in SMF.

And new to force Wedge to honor per-topic permission profiles.

When do you feature-lock this puppy?
I'm an SMF doc writer.

Arantor

  • As powerful as possible, as complex as necessary.
  • Posts: 14,278
Re: Privacy options
« Reply #31, on December 6th, 2011, 09:39 PM »
This wouldn't use the admin member group management area but be custom. It doesn't take long to whip up such things once we know what we're trying to build.

There's no way it would create a full member permissions profile, as that would massively overcomplicate something that doesn't need that level of depth. Permissions are inherently much simpler.

As far as implementing privacy goes, Nao already did a fair amount of the hard work before in Noisen.
When we unite against a common enemy that attacks our ethos, it nurtures group solidarity. Trolls are sensational, yes, but we keep everyone honest. | Game Memorial

Nao

  • Dadman with a boy
  • Posts: 16,082
Re: Privacy options
« Reply #32, on December 7th, 2011, 09:47 AM »
@Pete> I'm still unsure whether our query_see_topic should be before WHERE (i.e. use an inner join just like at noisen), or after it (i.e. use a subquery). Did you think about it..?
Quote from AngelinaBelle on December 6th, 2011, 09:34 PM
It will be complicated.
And scary, because you need to allow "everyone" to use stuff that was meant for only admin.
Easy enough to make the user moderator of the user's membergroups. New to make them able to create usergroups.
Well, as I said, Noisen did it very well. It wasn't scary at all, actually... In terms of security, there's nothing new compared to SMF. I don't think it took me more than a couple of days to implement the feature back then... That being said, it's not something I'm planning to implement in Wedge, because contact lists will be better suited IMHO. But they WILL probably be slower, that's for a fact. I guess I can still be convinced to use membergroups, but I'll need someone to debate with me ;)
The main reasons for not using membergroups are (1) the fact that the UI is complex, although it could be solved by writing an alternative UI for non-admins (I couldn't care less at the time...), (2) if you're someone 'popular' in a certain community and lots of people put you into their follow/contact lists, you'll end up with dozens of membergroup ownerships in your member account. If a forum is extremely popular, you could end up with your group field being overfilled (its size is 64KB at best IIRC). This could be solved by having a new table where members and membergroup relationships are stored. This isn't something I've explored so far... Maybe Pete has an opinion on this...?
Quote
When do you feature-lock this puppy?
No plans for now...
It will be feature-locked when it goes beta, I suppose. (And even then, we'll still be flexible about adding stuff that make sense.)

We used to have schedules and everything... Back when our relationship with SMF was bad at best. We wanted to release something in mid-2011 but because SMF eventually went gold around that time, it pretty much freed us of any restraints. Even when the main Noisen features are finally integrated, I'll still be wanting to finetune the overall design of Wedge because I'm not entirely happy with it. An important milestone will be when I install Wedge on this very website. This could be done today because the thought system is now ready to use (something Pete was adamant should be kept on Wedge.org), but thoughts led me to rethinking the privacy system, which in turn led me to rethink the select box stuff... Etc, etc. It's probably never going to end, but what matters is that Wedge is constantly evolving and not staying in its corner without any updates etc.

Arantor

  • As powerful as possible, as complex as necessary.
  • Posts: 14,278
Re: Privacy options
« Reply #33, on December 7th, 2011, 09:56 AM »
Quote
I guess I can still be convinced to use membergroups, but I'll need someone to debate with me
Whoever wants to argue that one will also have to convince me of it. It's just not a good idea IMO.
Quote
This could be solved by having a new table where members and membergroup relationships are stored. This isn't something I've explored so far... Maybe Pete has an opinion on this...?
64KB is a lot of space, and it allows for a lot to occur. That said, there's no real reason why it couldn't be made a mediumtext as opposed to a text; everything I've seen indicates there isn't any real problem in doing that, in the same way that text values aren't stored in the rowspace itself but in a separate area, so too with mediumtext, the only difference is that mediumtext offers 3 bytes per row not 2 (but while theoretically 16MB is wonderful, you actually hit other limits before hitting that one, 1MB is the largest safe insertion value on most systems)

That said, I'm inclined to go with one row per association rather than denormalise the data and stuff it in a text. It's cleaner, easier to maintain, less likely to get screwed up (cf the comments in Load.php about loading the user's groups and 'history shows that these can go bad')
Quote
This could be done today because the thought system is now ready to use (something Pete was adamant should be kept on Wedge.org)
Primarily because we use it so much. I post vastly more on there than I do on either Twitter or Facebook, for example.
Quote
@Pete> I'm still unsure whether our query_see_topic should be before WHERE (i.e. use an inner join just like at noisen), or after it (i.e. use a subquery). Did you think about it..?
I've thought about it and I just don't know. I can see benefits both ways of doing it - doing it before the WHERE will probably make it faster, but doing it after the WHERE only makes it easier to maintain and makes it easier for modders to apply it properly in their own things later on.

Nao

  • Dadman with a boy
  • Posts: 16,082
Re: Privacy options
« Reply #34, on December 7th, 2011, 03:10 PM »
Quote from Arantor on December 7th, 2011, 09:56 AM
Quote
I guess I can still be convinced to use membergroups, but I'll need someone to debate with me
Whoever wants to argue that one will also have to convince me of it. It's just not a good idea IMO.
Well, it does make things easier to manipulate in the long run, I suppose. SMF supports membergroups, but they're so complicated to manipulate, in the end there are never more than a dozen at a time. It could easily handle thousands of them...
Also, any extra feature added to contact lists could be used as well in regular membergroups: 'hidden' state (rather than hide the entire membergroup from view, why not hide just one person from view...?)

I didn't really consider this whole aspect because I'd given up on it at Noisen, but I didn't as well consider why I removed it from noisen -- primarily the UI issues, which I couldn't bother to deal with. Noisen's friend lists use the UltimateProfile code to manage friends, and this is something I'm going to rewrite anyway -- it's not like UP is BSD or whatever, AFAIK...
Quote
That said, I'm inclined to go with one row per association rather than denormalise the data and stuff it in a text. It's cleaner, easier to maintain, less likely to get screwed up (cf the comments in Load.php about loading the user's groups and 'history shows that these can go bad')
I'm not sure about rewriting all of the membergroup-related queries to use an extra table though... :P
Of course, it would also get us rid of these annoying find_in_set calls...
Quote
I've thought about it and I just don't know. I can see benefits both ways of doing it - doing it before the WHERE will probably make it faster, but doing it after the WHERE only makes it easier to maintain and makes it easier for modders to apply it properly in their own things later on.
I'd personally rather use the slower, but more 'natural' one. (Maybe it'll become a bigger issue if we ever have some successful installs.)
Either way, adding in {query_see_topic} "forces" us to always declare topics AS t, because the extra code will definitely use the alias. But IIRC it's the same with query_see_board anyway...
I'll just add that query_see_topic can be moved before or after the WHERE whenever we want -- it's not that big a deal because it's called at most 60-70 times in our code so it can be redone manually...

Arantor

  • As powerful as possible, as complex as necessary.
  • Posts: 14,278
Re: Privacy options
« Reply #35, on December 7th, 2011, 03:15 PM »
Quote
Also, any extra feature added to contact lists could be used as well in regular membergroups: 'hidden' state (rather than hide the entire membergroup from view, why not hide just one person from view...?)
The idea of hiding a membergroup is simply to prevent it showing up in the group key and/or the group listing, nothing more.

On the other hand, if it were turned into a global ignore feature to hide users who are a pain in the arse... that's something else entirely.
Quote
I didn't really consider this whole aspect because I'd given up on it at Noisen, but I didn't as well consider why I removed it from noisen -- primarily the UI issues, which I couldn't bother to deal with. Noisen's friend lists use the UltimateProfile code to manage friends, and this is something I'm going to rewrite anyway -- it's not like UP is BSD or whatever, AFAIK...
It's not, parts of it are GPL, the rest is ambiguous. Plus, it's not the prettiest mod ever written.
Quote
I'm not sure about rewriting all of the membergroup-related queries to use an extra table though...
Of course, it would also get us rid of these annoying find_in_set calls...
Boards already does this anyway without FIND_IN_SET. There aren't *that* many other places where group membership is validated with that, are there?
Quote
I'd personally rather use the slower, but more 'natural' one. (Maybe it'll become a bigger issue if we ever have some successful installs.)
Either way, adding in {query_see_topic} "forces" us to always declare topics AS t, because the extra code will definitely use the alias. But IIRC it's the same with query_see_board anyway...
I'll just add that query_see_topic can be moved before or after the WHERE whenever we want -- it's not that big a deal because it's called at most 60-70 times in our code so it can be redone manually...
Could always have {query_see_topic_join} and {query_see_topic_where} or similar. To answer your point, yes, {query_see_board} and its friends all rely on boards AS b being joined, just as SD/WD's {query_see_ticket} requires helpdesk_tickets AS hdt being joined.

Unless it's made into a subquery, it's impossible to avoid forcing a table join with alias.

Nao

  • Dadman with a boy
  • Posts: 16,082
Re: Privacy options
« Reply #36, on February 15th, 2012, 11:01 PM »Last edited on February 16th, 2012, 12:03 AM by Nao
I'm going to have to get started on this before I use Wedge on Wedge.org, I guess...

So, things to do: (feedback welcome.)

- query_see_topic everywhere (gonna be a lot of fun...)

- contacts table (still unsure whether 'contacts' is the right term to replace the awful 'buddies'. I still like 'friends' better, but if we want it to be usable by work colleagues and family etc, it should be a more generic term I think.)

- importing 'buddies' into contacts table at SMF import time, writing the UI to manipulate contact lists (will take it mostly from wedge.org...)

- would like to know the current 'official' positions of everyone on contact lists -- is it okay to use a contacts table, or should we ditch the whole concept of contacts, and instead allow everyone to create their own private/public membergroups?

Arantor

  • As powerful as possible, as complex as necessary.
  • Posts: 14,278
Re: Privacy options
« Reply #37, on February 16th, 2012, 12:15 AM »
I'm in agreement with the use of 'contacts' vs 'friends'.

As far as going with contacts, having a facility to track such things is no bad thing, especially as it covers stuff like easy-contact lists for the purpose of sending PMs, though I guess it depends how readily users can make contact lists themselves and how many lists they can have.

Nao

  • Dadman with a boy
  • Posts: 16,082
Re: Privacy options
« Reply #38, on February 16th, 2012, 12:23 AM »
One of my issues with contact lists is due to the privacy of current thoughts at wedge.org.
It'd be way easier for me to set privacy to id_group=friends group, like I did on the test site. But then new thoughts can't be posted to that group only because it's not implemented in the UI. And doing it... Well, maybe users would start getting confused between membergroups and contacts when time comes to choose a target privacy... thus, headache.
Additionally, I'm starting to think that I'll need extra columns for privacy... Just having a privacy flag won't cut it. I need id_group and id_contact_list fields, or something. Hm...

Aaron

  • Posts: 356
Re: Privacy options
« Reply #39, on February 16th, 2012, 12:34 AM »
Quote from Nao on February 15th, 2012, 11:01 PM
- contacts table (still unsure whether 'contacts' is the right term to replace the awful 'buddies'. I still like 'friends' better, but if we want it to be usable by work colleagues and family etc, it should be a more generic term I think.)
Agreed, contacts sounds more generic. Better than both 'friends' and --certainly-- 'buddies', I think.
Quote from Nao on February 15th, 2012, 11:01 PM
- would like to know the current 'official' positions of everyone on contact lists -- is it okay to use a contacts table, or should we ditch the whole concept of contacts, and instead allow everyone to create their own private/public membergroups?
Personally, I dislike the idea of users being able to create membergroups -- well, in the SMF sense of the word; especially if an admin is going to see them somewhere (which he technically should)...
"The entire British Empire was built on cups of tea … and if you think I'm going to war without one, mate, you're mistaken."

Nao

  • Dadman with a boy
  • Posts: 16,082
Re: Privacy options
« Reply #40, on February 16th, 2012, 10:55 AM »
Okay, I'll stick with 'contacts' then ;)

Admins are always going to be able to view custom groups, aren't they...? Would probably be the case for contact lists as well... Well, now that I'm thinking about it, it might be a good idea to hide these even from the admin if they're marked as private. I mean it's not like people can break a website this way...

Hmm, speaking of renaming...
"Send topic". This always bothered me. Not because I would never use that feature (I still wouldn't), but because it doesn't seem natural to me, in the age of Facebrood crap.
Why not rename it to "Share"...? This way, we could 'hook' other items into it -- share by e-mail/Facedoom/Twatter/Redditboughtthetshirt...
Heck, the French translation already says "Partager" (Share.)

PS: before anyone says so... I doubt very much that people would confuse it with the "Split topic" feature. :lol:
Re: Privacy options
« Reply #41, on February 16th, 2012, 10:33 PM »
Bump.

Also... I'm currently trying to determine what's best for implementing {query_see_topic}.

I'm thinking of a relatively different way, compared to what I did with Noisen.
Instead of looking for {db_prefix}topics and adding {query_see_topic} to these queries, I could instead look for any queries that have a "t.approved" test in them... (or just 'approved', just need to make sure it's for a topic)
Because these queries are seen as "protected", I should be able to replace these tests with query_see_topic. And of course, I'll be moving the t.approved test to the query_see_topic string... Which totally makes sense.

Only issue is, I'm not *sure* all of our added queries correctly follow t.approved and such... What do you think? Is this the right approach? Or should I just follow the query list from my Noisen patch, considering that it's been 100% proven as working?

Arantor

  • As powerful as possible, as complex as necessary.
  • Posts: 14,278
Re: Privacy options
« Reply #42, on February 16th, 2012, 10:42 PM »
Yes, t.approved (and m.approved, ma.approved and all the other aliases that get used on the tables in those queries) are 'protected' but they're protected in a funky way, i.e. based on owner and a permission. I'd argue that you need to leave that component alone, as well as adding the see_topic component to said queries.

Therein lies the problem: can, or should, a topic whose privacy is not explicitly 'everyone' be able to have unapproved posts?

Any queries we've added to the code should adhere to t.approved where it's currently been used, I can't think of a single query we might have added where it wasn't respected, with the exception of anything added in the admin panel where the rules are different anyway.

I'd also argue you pretty much do have to go by what's there and not necessarily by what's in the Noisen patch because there are going to be differences now that weren't in the original SMF code, which does mean looking through approved - there are, unfortunately, quite a few of those.

Nao

  • Dadman with a boy
  • Posts: 16,082
Re: Privacy options
« Reply #43, on February 16th, 2012, 10:50 PM »
Quote from Arantor on February 16th, 2012, 10:42 PM
Yes, t.approved (and m.approved, ma.approved and all the other aliases that get used on the tables in those queries) are 'protected' but they're protected in a funky way, i.e. based on owner and a permission. I'd argue that you need to leave that component alone, as well as adding the see_topic component to said queries.
I noticed one of these 'funky' variations, and I'm unsure what of think of them... :-/
e.g. if I'm putting the condition at the same level as the is_approved, which is probably what 'should' be, then why not simply have the approved test inside the query_see_topic...? I really can't think of a reason not to, right now. If someone has the right to modify/delete/whatever a topic because of a permission, then surely they should be allowed to view it if it's not technically a topic they should be able to read... It's a moderator's job. No?
Quote
Therein lies the problem: can, or should, a topic whose privacy is not explicitly 'everyone' be able to have unapproved posts?
I have no idea... I'd tend to say yes, otherwise it gets complicated.
Quote
Any queries we've added to the code should adhere to t.approved where it's currently been used, I can't think of a single query we might have added where it wasn't respected, with the exception of anything added in the admin panel where the rules are different anyway.
There are only a few queries about topics in the admin anyway.
Quote
I'd also argue you pretty much do have to go by what's there and not necessarily by what's in the Noisen patch because there are going to be differences now that weren't in the original SMF code, which does mean looking through approved - there are, unfortunately, quite a few of those.
Noisen patch = still 440KB to implement. Of these, many, many KB are about the query_see_topic code... I'm a bit wary of removing the patch code without checking the implementation... :^^;:

BTW, if no one comments on the logo topic any longer... Does that mean I get to choose our final logo? :whistle:

Arantor

  • As powerful as possible, as complex as necessary.
  • Posts: 14,278
Re: Privacy options
« Reply #44, on February 16th, 2012, 10:56 PM »
Quote
e.g. if I'm putting the condition at the same level as the is_approved, which is probably what 'should' be, then why not simply have the approved test inside the query_see_topic...?
Because the condition for approval is evaluated at both topic and message level. If the entire topic isn't approved, then it can safely be made part of the query_see_topic - however, test first that $settings['postmod_rules'] is non empty before adding that condition in, if it's empty, don't have the approval condition at all.

That's the thing about permissions... being able to split, merge, delete, whatever, they're all dependent on being able to see the topic. If they can't see it, they can't see it and no other granting of permissions will change that small detail, not really should it.
Quote
I have no idea... I'd tend to say yes, otherwise it gets complicated.
*nods* Then we just have to deal with the fact that approval is one method of a topic being hidden rather than being separate and something else.
Quote
There are only a few queries about topics in the admin anyway.
True enough. The one I'm really thinking of that's affected here is post counts.
Quote
I'm a bit wary of removing the patch code without checking the implementation...
That's a valid statement, I'd just wonder how far other queries have come since the Noisen patch though. Stuff like the blog changes to message/display pages for example.
Quote
BTW, if no one comments on the logo topic any longer... Does that mean I get to choose our final logo?
I think you have a pretty good idea on what I like and what I don't like, though I have the tab open still to reply to (and read, really) and I'm not that fussy. The fact that while I appreciated the idea of the fulcrum, I actually actively disliked the exact style SMF used themselves never otherwise put my off contributing ;) Seriously though, I don't mind too much provided that it's legible and nice.
« The Regular Members group
Image resizing for non-uploads »