Wedge

Arantor · « Reply #**105**, on February 23rd, 2012, 04:02 PM »

Quote

Well, that's what I'm saying: it is... It's tested whatever the postmod_active state.
BTW, where the hell do I enable postmod?! Now that core features are gone... Well, I even made an admin search and didn't find any 'master' setting?!

There isn't a master setting any more :P

Quote

...I don't get it. If testing for m.approved=0, m.approved=1 or nothing at all, same performance. How can it be, since in the last case we're sure not to ever use the approved index...?

Putting the WHERE clause in is more expensive than not having it. If it isn't necessary to test it, don't have that clause in.

Quote

Hmm... That does seem like something that might confuse people. It confuses even me...
Is it working, at least? Last time you didn't have the Save feature for it, so I left it aside but now I need to have postmod enabled just to test my code...

Oh, it works. The only thing that doesn't work properly (out of what is shown) is the textual matches, when you're using any of the HTML special characters, they get encoded properly for sending, are stored properly but the regex doesn't apply them properly at this point. (There is still more to implement here, though, like user id and permissions tests)

Quote

Heck, can anyone actually view an unapproved topic if they don't have permission to, but they know its ID? Because I can't see any code to stop them in Display.php! Actually noisen.com/wedge.org do have such code, that's where it gets funny. Well, they don't add approved flags to the mix but at least they support 'justme' privacy.

Now you understand why I was so fussy about the whole loadBoard thing. loadBoard is supposed to deal with that.

I know in SMF if you have a topic whose ID you know but it's moderated, you can only see it if you're the owner or a moderator with suitable permissions, but it's enforced by loadBoard as far as I can tell, not by Display. Display assumes to a point that if you can see the board, you can see the topic.

Nao · « Reply #**106**, on February 23rd, 2012, 05:15 PM »

Quote from Arantor on February 23rd, 2012, 04:02 PM

There isn't a master setting any more :P

But how can I enable it, at all?
See, post moderation is not just about filtering new posts... It's also about being able to unapprove posts (something we're still not doing, AFAIK...), which we won't be able to do if this happens. How about adding a master setting to the filter page...? Plus, it would allow admins to disable their filters without having to delete them, if that's not possible right now.

BTW I went ahead and looked at the page. I was a bit confused with the order. For instance, you can change the 'new post' or 'new topic' item after making new rules. I think it'd be more understandable if it was disabled, or hidden and repeated as a simple text string in the next fieldset. Also, the 'posting in these boards' thing may be confusing as well. I know that my direct French translation made me feel unsure about it. I changed it to 'posté dans ces sections', meaning 'postED in these boards', but I'm not sure it's the best.

Finally, it'd be nice to have slideDown animations, I think, instead of simple toggles. Perhaps a fade in for the "Save rule" button, because it's not always clear that the "Save filter" button is being hidden and replaced by another (even though the new one is inside the fieldset rather than outside). If it's going to be a wizard, it should be super-user-friendly, which right now I'm not sure it sure. I'd like to know your opinion on this.

Quote

Quote
...I don't get it. If testing for m.approved=0, m.approved=1 or nothing at all, same performance. How can it be, since in the last case we're sure not to ever use the approved index...?
Putting the WHERE clause in is more expensive than not having it. If it isn't necessary to test it, don't have that clause in.

But we always need a WHERE clause, I never met a single case where a post-mod test was being done and the WHERE was added only for it.

See, this is what I don't get: I'm saying that SMF/Wedge has t.approved tests done *only* if postmod_active is enabled, while m.approved tests are done without testing for postmod_active first. It seems to me that m.approved is slower than t.approved (because of relative table sizes), so it should be the one with systematic postmod tests, not the other way around...

Quote

Oh, it works. The only thing that doesn't work properly (out of what is shown) is the textual matches, when you're using any of the HTML special characters, they get encoded properly for sending, are stored properly but the regex doesn't apply them properly at this point.

Want me to look into it?

Quote

Quote
Heck, can anyone actually view an unapproved topic if they don't have permission to, but they know its ID? Because I can't see any code to stop them in Display.php! Actually noisen.com/wedge.org do have such code, that's where it gets funny. Well, they don't add approved flags to the mix but at least they support 'justme' privacy.
Now you understand why I was so fussy about the whole loadBoard thing. loadBoard is supposed to deal with that.

Were you? I didn't notice... :^^;:

Quote

I know in SMF if you have a topic whose ID you know but it's moderated, you can only see it if you're the owner or a moderator with suitable permissions, but it's enforced by loadBoard as far as I can tell, not by Display. Display assumes to a point that if you can see the board, you can see the topic.

I'd be curious to know if this happens in stock SMF installs. I can't do it for my sites because they all use my custom code, but to anyone with a forum: please enable post moderation, post an unapproved topic, and use a low-level account to access it directly by ID... Does it show you the topic? What about the post itself?

Arantor · « Reply #**107**, on February 23rd, 2012, 05:29 PM »

Quote

But how can I enable it, at all?
See, post moderation is not just about filtering new posts... It's also about being able to unapprove posts (something we're still not doing, AFAIK...), which we won't be able to do if this happens. How about adding a master setting to the filter page...? Plus, it would allow admins to disable their filters without having to delete them, if that's not possible right now.

The only way to do it is to create a new rule. Though, I guess we could add a tickbox, but I think it's going to be incongruous and out of place (which is why I deliberately didn't go down that road, and tied it into the rules logic as it currently is)

As for disabling a filter without deleting it - why would you? Either it's not working for you and needs editing, or it is working and should be left alone.

Quote

BTW I went ahead and looked at the page. I was a bit confused with the order. For instance, you can change the 'new post' or 'new topic' item after making new rules. I think it'd be more understandable if it was disabled, or hidden and repeated as a simple text string in the next fieldset. Also, the 'posting in these boards' thing may be confusing as well. I know that my direct French translation made me feel unsure about it. I changed it to 'posté dans ces sections', meaning 'postED in these boards', but I'm not sure it's the best.

Yup, because you might decide to change the scope of the rule, e.g. you set it to new topics by accident but want to switch it to all posts.

As for 'posting in these boards', I couldn't think of a better way to phrase it. I suppose past tense is more correct, but the idea is to convey the notion that if the post is made in one of the boards you're picking (or not, depending on situation), that the rule will apply.

Quote

Finally, it'd be nice to have slideDown animations, I think, instead of simple toggles. Perhaps a fade in for the "Save rule" button, because it's not always clear that the "Save filter" button is being hidden and replaced by another (even though the new one is inside the fieldset rather than outside). If it's going to be a wizard, it should be super-user-friendly, which right now I'm not sure it sure. I'd like to know your opinion on this.

slideDown/slideUp didn't occur to me at all when building it, but I agree (having seen it used in the paid subs area too)

Quote

But we always need a WHERE clause, I never met a single case where a post-mod test was being done and the WHERE was added only for it.

That's not what I mean.

SELECT ... WHERE stuff is always going to outperform SELECT ... WHERE stuff AND m.approved... unless (and only unless) the stuff in the first place excludes everything anyway. If there are any rows found by the stuff clauses, they will have to be evaluated by m.approved.

Quote

See, this is what I don't get: I'm saying that SMF/Wedge has t.approved tests done *only* if postmod_active is enabled, while m.approved tests are done without testing for postmod_active first. It seems to me that m.approved is slower than t.approved (because of relative table sizes), so it should be the one with systematic postmod tests, not the other way around...

And... hang on... it is testing for m.approved only when postmod is active.

Code: [Select]

	// Get each post and poster in this topic.
	$request = wesql::query('
		SELECT id_msg, id_member, modified_member, approved, poster_time
		FROM {db_prefix}messages
		WHERE id_topic = {int:current_topic}' . (!$settings['postmod_active'] || allowedTo('approve_posts') ? '' : (!empty($settings['db_mysql_group_by_fix']) ? '' : '
		GROUP BY id_msg') . '
		HAVING (approved = {int:is_approved}' . ($user_info['is_guest'] ? '' : ' OR id_member = {int:current_member}') . ')') . '
		ORDER BY id_msg ' . ($ascending ? '' : 'DESC') . ($context['messages_per_page'] == -1 ? '' : '
		LIMIT ' . $start . ', ' . $limit),
		array(
			'current_member' => $user_info['id'],
			'current_topic' => $topic,
			'is_approved' => 1,
			'blank_id_member' => 0,
		)
	);

That's in Display.php. That's the query that identifies what posts are to be displayed, everything after that shouldn't be filtering it.

Quote

Want me to look into it?

Can do if you like... it doesn't help that the rules are non typical because of the whole entity 039 thing, and the fact that the regex raw type should expressly not perform that operation (because you'd end up screwing up <= operators in the regex for example) while the others should perform it.

Quote

I'd be curious to know if this happens in stock SMF installs. I can't do it for my sites because they all use my custom code, but to anyone with a forum: please enable post moderation, post an unapproved topic, and use a low-level account to access it directly by ID... Does it show you the topic? What about the post itself?

I discovered this on sm.org in their showcase board when I was a Friend. I'd see topics in the message index I wasn't supposed to but because they weren't approved I couldn't actually see the topics themselves. loadBoard should deal with that AFAIK.

Nao · « Reply #**108**, on February 23rd, 2012, 05:32 PM »

Quote from Arantor on February 23rd, 2012, 10:50 AM

Maybe that suggests a rethink of how the moderator badge is applied is in order. Perhaps, even, have it in addition to (rather than instead of) the standard badge?

I don't know. It screams "admin setting" to me, because some admins will want two badges, others will want to show moderator badges, and others like me will want to show regular badges if available... :-/
What do you think?

Quote

They won't, it's a standard permission. But specifically it is a general permission, not a board one, so board level moderators never get the chance to have it in the first place (because that's the quirk of group 3 - it never has general permissions)

Hmm yes, that's the way it should be. I think I meant moderate_forum per se, though. Does giving moderate_forum permission to someone, also give them implicitly (or explicitly through code I couldn't find), the issue_warning permission...?

Quote

So yes, it's a bug - they have the power to see the warn button but not to actually use it.

Yay, a SMF bug :P

Quote

Sure it is, but as group 3 is special in other ways you can expressly do things with it that you can't with a bare allowedTo() check.

I'm giving up trying to understand what that group is meant to do/be... :^^;:

Quote

The only issue I have is with the FIND_IN_SET - but there's no way around it.

There's a way about it, it's using the contact table :P Which we'll do, as it's already in the DB...

Quote

Quote
After all, it's not like adding query_see_topic will break anything. It can be done gradually
I'm not used to features that can be added gradually :P

Well, turns out it was a quick implementation, eh...? Although, you know how I am, I'm still going to check every single occurrence of query_see_topic in the Noisen code and make sure they're in our code, and if not, that it was really not needed at all.
Too bad that the very first occurrence was in Display.php... Which spawned a discussion of its own ;)

Quote

Quote
I wouldn't be able to determine what's best, between "mirror from profile..", "mirror profile", "alias of profile..." or whatever makes sense.
I'll think about it, got a lot of personal stuff going on today :(

If anything, a help icon would be best. To take time and explain...

Quote

Point is: some queries that look like they need query_see_topic actually don't, because loadBoard should take care of them, or at least if loadBoard takes care of them, other places don't have to as much.

Oh, so THAT was what you were referring to... :lol:
Sorry, hadn't read this post yet, it was in a tab waiting for a proper reply ;)
Well, I suppose we could add something in loadBoard... Check $topic, and if it's filled, add a query_see_topic?

Quote

Quote
I just said that if we have to store an extra integer for the contact list ID, then we might as well enable Wedge to store a group ID in that same place...
*nods* But that's only really true for holding a single value - the minute you start trying to hold a relationship in there it's going to go to hell.

Hmm... A relationship, you mean a comma separated list?
Hey, how about we keep a table with proper relationships...?
{db_prefix}topic_privacy
id_privacy = unique ID
id_topic = topic ID
privacy = privacy type?
privacy_id = ID of group or contact or member, depending what's in the privacy type

{db_prefix}topics
privacy = privacy type?

The topic table could check for privacy type, and if != 'default', do a subselect on wedge_topic_privacy using its own topic ID, trying to determine whether we belong to the privacy_id list.

Because topic privacy is unlikely to be used on a majority of topics, it would keep the table quite small. Maybe we could even get rid of any privacy fields in the topic table, and just do a LEFT JOIN but I don't think it's very practical to do, just a silly idea.

Quote

The problem comes in when you query a table with such records, and actually retrieve the text/blob. In those situations, if you do any ordering, it triggers a filesort rather than an in-memory table.

Hmm, so it's definitely a no-no...

Posted: February 23rd, 2012, 05:29 PM

I really, REALLY want to know what you drink or eat to be able to answer things so quickly and so thoroughly.
I just can't keep up :P

Quote from Arantor on February 23rd, 2012, 10:50 AM

Yup. But in the case of thoughts at least, depending on permissions checks (which are basically free in DB terms), you can exclude things on a more granular nature, rather than on a permissions flag. Consider, if you do 'permission to view thoughts' and 'permission to view replies', the former obviates any need to query at all,

But I'm not sure it's any good. I mean, why would I would people to be able to view something or not? I want authors to be able to determine that themselves... They're the ones who should know whether they want a thought to be public or private.
Call it a dream or folly, but I want people to be able to think freely! :P :P

Quote

Oh... I just realised I'm a doofus (based on your earlier post), because I mistakenly thought it was the current user's friend list which is already loaded and available, rather than the topic starter's (which can't be done without some kind of lookup)

I think I lost you here :P Too many things being discussed...

Arantor · « Reply #**109**, on February 23rd, 2012, 05:37 PM »

Quote

I don't know. It screams "admin setting" to me, because some admins will want two badges, others will want to show moderator badges, and others like me will want to show regular badges if available...

Some will want to show multiple badges too - e.g. if you have multiple groups. It's not an easy thing to solve.

Quote

Hmm yes, that's the way it should be. I think I meant moderate_forum per se, though. Does giving moderate_forum permission to someone, also give them implicitly (or explicitly through code I couldn't find), the issue_warning permission...?

Not that I'm aware of. issue_warning is a regular permission in the permissions area.

Quote

Yay, a SMF bug

In the same way that YaBB was Yet Another Bulletin Board, perhaps Wedge 1.0 should be codenamed YaSBS - Yet another SMF bug squished :P

Quote

I'm giving up trying to understand what that group is meant to do/be...

The group's purpose for existence is to be able to configure what board moderators - added through manage boards - can do. By making it a physical group you can set its colour, badge, permissions etc. And because it's a special group it has special behaviour - like overriding badges.

Quote

There's a way about it, it's using the contact table Which we'll do, as it's already in the DB...

A subselect should be faster than a FIND_IN_SET, I believe.

Quote

Well, I suppose we could add something in loadBoard... Check $topic, and if it's filled, add a query_see_topic?

Yup, sounds like a plan - it would nail down a lot of edge cases that rely on that behaviour.

Quote

Hmm... A relationship, you mean a comma separated list?
Hey, how about we keep a table with proper relationships...?

Well, I wasn't going to get into the how, but stay at the 'what' to start with; it's a relationship in that you're indicating some relation between two pieces of data. Doing that in a CSV list is not ideal for a bunch of reasons.

A table would be better but you still have to get the query running nicely, though having the option of subqueries should help.

Quote

Because topic privacy is unlikely to be used on a majority of topics, it would keep the table quite small. Maybe we could even get rid of any privacy fields in the topic table, and just do a LEFT JOIN but I don't think it's very practical to do, just a silly idea.

Doing the left join would probably be faster actually.

Quote

Hmm, so it's definitely a no-no...

If you're trying to sort by it, yes.

Quote

I really, REALLY want to know what you drink or eat to be able to answer things so quickly and so thoroughly.

A healthy dose of computer addiction ;)

Quote

But I'm not sure it's any good. I mean, why would I would people to be able to view something or not? I want authors to be able to determine that themselves... They're the ones who should know whether they want a thought to be public or private.

Consider it here. Who sets the rules about thoughts here? It's done based on whether you're a Friend or not... isn't that really the same thing as what I'm talking about?

Nao · « Reply #**110**, on February 23rd, 2012, 06:19 PM »

:edit: Okay, that was a long post... Could you go through it and, while you're reading, compile a list of everything we're discussing in it, and what needs to be done, what needs to be further discussed, etc...? Because I'm feeling lost. And the more I talk about something, the less time I have to work on it ;)

Quote from Arantor on February 23rd, 2012, 05:29 PM

The only way to do it is to create a new rule.

And it's going to cause many people to ask about it... Then we'll make a FAQ rule, that people won't read... Then you'll give up and add a master setting :P
There's already a moderation entry in the main admin settings menu, so we could have the master moderation setting there, something like "Enable Post Approval and Moderation Rules", maybe something shorter, and depending on that setting, we show the moderation filters menu or not... (Although it's likely that you'll want to have it very much in everyone's sight for starters, if only because it's a powerful new Wedge feature...) (Well, that could be a good opportunity to set post moderation by default.)

One possibility I just thought of, to make post mod faster... We keep a list of unapproved posts, right? I remember seeing that setting in the code I dabbled with this morning. Well, how about we simply add, in query_see_topic, a PHP check to see if there are any unapproved posts... If anything's found, add the t.approved code as needed. Otherwise, skip it!

Quote

Though, I guess we could add a tickbox, but I think it's going to be incongruous and out of place (which is why I deliberately didn't go down that road, and tied it into the rules logic as it currently is)

Your logic itself is sound and very commendable. I'm more worried about our users' logic. And mine :P

Quote

As for disabling a filter without deleting it - why would you? Either it's not working for you and needs editing, or it is working and should be left alone.

I don't know -- just say you wanna test whether the filter is actually useful, so you disable it for a while, and if spam comes back or whatever, you re-enable it.
Or if a pre-moderated area is quite slow and you're going on vacation and want people to be able to post freely to it -- you disable it, until you come back and re-enable it without having to worry about re-entering a list of filters or whatever.

Quote

Yup, because you might decide to change the scope of the rule, e.g. you set it to new topics by accident but want to switch it to all posts.

Then I think it should be 'acknowledged' at the very least, for instance in the rule settings, instead of 'Posting in...', have something like 'Creating new topic in...' or 'Sending new post in...'?

Quote

As for 'posting in these boards', I couldn't think of a better way to phrase it. I suppose past tense is more correct, but the idea is to convey the notion that if the post is made in one of the boards you're picking (or not, depending on situation), that the rule will apply.

Your way of phrasing it is correct, it's just harder to understand on first use. It might be better with the suggestions I wrote above.

Quote

slideDown/slideUp didn't occur to me at all when building it, but I agree (having seen it used in the paid subs area too)

Yeah, I like them a lot eheh. I try and use them anywhere I can.
One of the annoying things with these JS toggles though (it's valid for both slide and immediate toggles), is that if you go back to a page (Back button) where you'd changed an opened div, usually the default opened setting will be reestablished and the default selection will stay the same (or the other way around), meaning you have to click once or twice to reset it the way you wanted. Anyway... It's just a minor tidbit, and something I never found a solution for.

Quote

SELECT ... WHERE stuff is always going to outperform SELECT ... WHERE stuff AND m.approved... unless (and only unless) the stuff in the first place excludes everything anyway. If there are any rows found by the stuff clauses, they will have to be evaluated by m.approved.

And if it only finds a few entries, it doesn't matter that m.approved is slow ;)
I noticed earlier today while making my commit, that I'd at some put put a query_see_topic at the beginning of a query instead of the end. Oops! I immediately moved it to the end, specifically because I figured it would be evaluated last and thus would be much less expensive. So I was right, right?

Quote

And... hang on... it is testing for m.approved only when postmod is active.

Yes, in many queries. But not all... Look at Recent.php, for instance. There are more like that. I left them as is because I figured we should discuss it first. (Believe me, I did most of the hard work this morning with t.approved stuff... Was a bit messy and I believe I managed to make it behave, but m.approved, oh man, don't tell me I'm going to spend my day on this so I'll just discuss it :P)

Quote

Can do if you like... it doesn't help that the rules are non typical because of the whole entity 039 thing,

Oh, my... That again? Oh, I try not to touch these with a 10-foot pole... It gave me nightmares so many times before. I'm so tempted to modify the import tool so that it converts all of these 39 and 039 entities to single quotes on the fly, but then I know I'll also have to review the entire Wedge codebase to try and make sure it doesn't keep sending these to the database... :^^;: (Heck, maybe we could hook into the wesql code to check for 'body parts' and replace 039 on the fly...)

Quote

I discovered this on sm.org in their showcase board when I was a Friend. I'd see topics in the message index I wasn't supposed to but because they weren't approved I couldn't actually see the topics themselves. loadBoard should deal with that AFAIK.

So it's the opposite of what I thought, right...? I thought that people wouldn't be able to see the topics in the topic list, but would be able to access them by ID...

Quote

Some will want to show multiple badges too - e.g. if you have multiple groups. It's not an easy thing to solve.

That's what I'm saying... An admin setting would be good for that. Even the SMF codebase refers in a comment to how there are several schools of thought on this...
It may be just a detail, but if it can save us from people asking for a plugin for this... And I don't even know if it'd be doable as a plugin anyway ;)

Quote

Quote
Hmm yes, that's the way it should be. I think I meant moderate_forum per se, though. Does giving moderate_forum permission to someone, also give them implicitly (or explicitly through code I couldn't find), the issue_warning permission...?
Not that I'm aware of. issue_warning is a regular permission in the permissions area.

Ah, bugger...
Then again, I'd tend to go to someone's membergroup and check permissions accordingly. But it's always unclear what moderate_forum does. Plus, SMF/Wedge tends to... be a bit lazy about it, and sometimes it adds allowedTo('moderate_forum') for something, where in other situations it won't...

Quote

In the same way that YaBB was Yet Another Bulletin Board, perhaps Wedge 1.0 should be codenamed YaSBS - Yet another SMF bug squished :P

More like YaPoS to me. Don't ask me what that stands for. :niark:

Quote

A subselect should be faster than a FIND_IN_SET, I believe.

If not, then there's no point in using extra tables and such... Imagine a whole world running on FIND_IN_SET... Lol, what a mess :lol:

Quote

Quote
Well, I suppose we could add something in loadBoard... Check $topic, and if it's filled, add a query_see_topic?
Yup, sounds like a plan - it would nail down a lot of edge cases that rely on that behaviour.

Okay, doing that right now.
Okay, done.
Interestingly, it was already done this way... I just had to add the AND {query_see_topic} to the INNER JOIN. Problem solved. Hopefully!

Quote

A table would be better but you still have to get the query running nicely, though having the option of subqueries should help.

It isn't exactly fantastic to add two tables (I suppose -- one for topics and one for thoughts), but it would probably be best if anything. Plus, allows for fantastic fine-tuning of topic privacy... I mean, if you can actually enter specific member names... Everyone will be over the moon! Another good reason to switch to Wedge :P

Oh, and reminds me of something... Maybe, MAYBE we should allow for topic privacy to be respected even by admins... I mean, somehow, it's exactly like private messages, or PMs sent to multiple recipients (in the case of "contact-list-based topic privacy").

Quote

Quote
Because topic privacy is unlikely to be used on a majority of topics, it would keep the table quite small. Maybe we could even get rid of any privacy fields in the topic table, and just do a LEFT JOIN but I don't think it's very practical to do, just a silly idea.
Doing the left join would probably be faster actually.

You think...? Because it would be run even if topic privacy is set to default... (Of course, it wouldn't return anything.)
Well, technically it couldn't be a left (or inner) join I think -- if it doesn't find anything, does it mean it's a public topic, or it's private but you can't access it...?

Quote

A healthy dose of computer addiction ;)

And I'm not even getting started on this forum I found through googling for 'wedge fork' a couple of days ago, 'anotheradminforum', where I was surprised to find you and a bunch of our members discussing Wedge and other things... And nobody even cared to tell me :P Of course, you *had* to post nearly 3000 posts over there in the last 4-5 months, which is more than your post output on wedge.org... And I thought you'd gone quieter over the end of the last year :P

Quote

Quote
But I'm not sure it's any good. I mean, why would I would people to be able to view something or not? I want authors to be able to determine that themselves... They're the ones who should know whether they want a thought to be public or private.
Consider it here. Who sets the rules about thoughts here? It's done based on whether you're a Friend or not... isn't that really the same thing as what I'm talking about?

Not really...?

My concept:

Admin: does nothing
Author: determines who can view their thoughts
User: views thoughts based on author's decision

Your concept:

Admin: determines who can view thoughts and replies
Author: determines who can view their thoughts... Well, APART from the people prevented from doing so by the admin
User: views thoughts based on author's and admin's decision

A penny for your thought. I believe in freedom of speech -- and thought. Admins could possibly disable the thought system (which I'm wary of -- considering I haven't even begun to implement this in the first place... not because of laziness but because of freedom), but I'm not sure there's a point in letting them determine that only a single membergroup can access thoughts.

Of course, I *suppose* you thought of that because of Wedge.org's current implementation -- you're thinking that it'd be simpler to just give 'View thought replies' permissions to Friends, and 'View thoughts' permissions to everyone else... Right?

Arantor · « Reply #**111**, on February 23rd, 2012, 06:45 PM »

Quote

Because I'm feeling lost. And the more I talk about something, the less time I have to work on it

You're not alone in that feeling >_<

Quote

And it's going to cause many people to ask about it... Then we'll make a FAQ rule, that people won't read... Then you'll give up and add a master setting

If it requires a FAQ rule, it's already broken :lol: OK, then, put it in and we can see if it's necessary or not (it's not like we can't remove it in a later version if needed)... making such a setting be taken care of is as simple as updating Load.php to check for !empty($settings['postmod_rules']) || !empty($settings['postmod_override']) or whatever you want to call it.

Quote

There's already a moderation entry in the main admin settings menu, so we could have the master moderation setting there, something like "Enable Post Approval and Moderation Rules", maybe something shorter, and depending on that setting, we show the moderation filters menu or not... (Although it's likely that you'll want to have it very much in everyone's sight for starters, if only because it's a powerful new Wedge feature...) (Well, that could be a good opportunity to set post moderation by default.)

We could certainly have a link to the moderation filters area from there. I don't like the idea of just configuring an option directly from the menu though.

Quote

One possibility I just thought of, to make post mod faster... We keep a list of unapproved posts, right? I remember seeing that setting in the code I dabbled with this morning. Well, how about we simply add, in query_see_topic, a PHP check to see if there are any unapproved posts... If anything's found, add the t.approved code as needed. Otherwise, skip it!

There is, of sorts, an approval queue, yes. It's a table with a single column, id_msg. We don't track topics, only the messages themselves.

In any case, doing what amounts to SELECT ... FROM topics WHERE id_topic NOT IN (list) is actually very slow. The indexes are very good at finding what's there, but not so good at finding what isn't there - instead of using the index, they have to go through and attempt to match each one. It isn't pretty. (Incidentally, it's why the stock implementation of ignore topics is so painful.)

Quote

Your logic itself is sound and very commendable. I'm more worried about our users' logic. And mine

The logic may be sound, doesn't mean it's right ;) Let's give it a try and see what happens.

Quote

I don't know -- just say you wanna test whether the filter is actually useful, so you disable it for a while, and if spam comes back or whatever, you re-enable it.
Or if a pre-moderated area is quite slow and you're going on vacation and want people to be able to post freely to it -- you disable it, until you come back and re-enable it without having to worry about re-entering a list of filters or whatever.

Hmm, there's actually nowhere in the system to be able to activate or deactivate a filter. I guess one can be added, though.

Quote

Then I think it should be 'acknowledged' at the very least, for instance in the rule settings, instead of 'Posting in...', have something like 'Creating new topic in...' or 'Sending new post in...'?

I guess. It's an extra string, but that's no biggie, of course.

Quote

Your way of phrasing it is correct, it's just harder to understand on first use. It might be better with the suggestions I wrote above.

To be honest, I never quite envisaged the mod filters stuff as 'finished' (notwithstanding the bits I haven't yet finished UI-wise generally), but more 'mostly done, just needs polish'. I fully expect to deploy it to users, get some feedback and polish out the rough edges that I couldn't initially see from being 'too close' to it.

Quote

Yeah, I like them a lot eheh. I try and use them anywhere I can.

They're pretty nice, just I'd never thought of them before. On the subject of toggles, note that slideToggle and toggle do behave differently as far as forcing a state goes (slideToggle(false) does not do the same overall thing toggle(false) does)

Quote

I noticed earlier today while making my commit, that I'd at some put put a query_see_topic at the beginning of a query instead of the end. Oops! I immediately moved it to the end, specifically because I figured it would be evaluated last and thus would be much less expensive. So I was right, right?

Yes. Query conditions are evaluated much as they are in PHP, from left to right with AND/OR working much the same way. One thing... the order that fields are used in conditions is normally supposed to be the same order that the components of a primary/other key are supposed to be, but it's probable they fixed that limitation some time ago.

Quote

Yes, in many queries. But not all... Look at Recent.php, for instance. There are more like that. I left them as is because I figured we should discuss it first.

Ugh. My understanding was that if postmod isn't active, the checks shouldn't be performed. Anything contrary to that is a bug, especially since disabling postmod forced everything to be approved anyway. (It's not like us where clearing the rules leaves things unapproved!)

Quote

Oh, my... That again? Oh, I try not to touch these with a 10-foot pole...

Oh yes. And it's not directly solvable just by doing that either, e.g. cases of XSS injection attempts get foiled here.

Quote

So it's the opposite of what I thought, right...? I thought that people wouldn't be able to see the topics in the topic list, but would be able to access them by ID...

Pretty much, yeah.

Quote

Then again, I'd tend to go to someone's membergroup and check permissions accordingly. But it's always unclear what moderate_forum does. Plus, SMF/Wedge tends to... be a bit lazy about it, and sometimes it adds allowedTo('moderate_forum') for something, where in other situations it won't...

It's certainly inconsistent. moderate_forum is a very nasty permission because it covers more things than most people realise. The description for moderate_forum is 'moderate forum members' and the official help on it describes it as:

* access to registration management
* access to the view/delete members screen
* extensive profile info, including track IP/user and (hidden) online status
* activate accounts
* get approval notifications and approve accounts
* immune to ignore PM
* several small things

Quote

If not, then there's no point in using extra tables and such... Imagine a whole world running on FIND_IN_SET... Lol, what a mess

SMF was written in a world where FIND_IN_SET was the norm, because it specifically used to kick back subselects. And I believe 2.0 may still run on versions of MySQL where subselects aren't even available.

Quote

Oh, and reminds me of something... Maybe, MAYBE we should allow for topic privacy to be respected even by admins... I mean, somehow, it's exactly like private messages, or PMs sent to multiple recipients (in the case of "contact-list-based topic privacy").

I'm on the fence about that. Private messages are not private in reality, they are merely personal. Though the core doesn't allow the admin to access it, it also doesn't do anything to prevent it (e.g. obfuscation of the data)

Quote

You think...? Because it would be run even if topic privacy is set to default... (Of course, it wouldn't return anything.)
Well, technically it couldn't be a left (or inner) join I think -- if it doesn't find anything, does it mean it's a public topic, or it's private but you can't access it...?

Sure it would still be run, but the table it's joining to would be similarly small, so you'd just get an empty column coming back. If the table's small enough to be in memory it's going to be fast.

Quote

And I'm not even getting started on this forum I found through googling for 'wedge fork' a couple of days ago, 'anotheradminforum', where I was surprised to find you and a bunch of our members discussing Wedge and other things... And nobody even cared to tell me Of course, you *had* to post nearly 3000 posts over there in the last 4-5 months, which is more than your post output on wedge.org... And I thought you'd gone quieter over the end of the last year

To be fair, though, those posts take less mental effort to do. They're also, typically, a *lot* shorter than my posts here. Besides, we're at the stage now where I'm doing a little bit of positive marketing without having to deal with "Post here and... and I'll fucking spank you"[1] whilst still reaching people who might actually give two hoots.

Quote

Of course, I *suppose* you thought of that because of Wedge.org's current implementation -- you're thinking that it'd be simpler to just give 'View thought replies' permissions to Friends, and 'View thoughts' permissions to everyone else... Right?

Correct. That's how it is here and that seemed perfectly workable to me ;)

The thing is, privacy controls are wonderful - but they're also complex, no matter how you do them, unless your interface is totally geared to it - which is why G+ got it quite right, because so much dev time and effort went on the interface. Meanwhile, for what is, proportionate to the actual act of posting in a forum, a minor feature - privacy on thoughts is a bit more complicated than perhaps it needs to be.

If I don't care whether people can see it, I'll post it as a thought. If I do care who can see it, I'll post it in the relevant board.

1.	Apologies to Kevin Smith.

Nao · Posted: February 26th, 2012, 03:16 AM

Looks like you didn't compile the list I asked you to do... I know, I know, it's annoying for you too :P

Quote from Arantor on February 23rd, 2012, 06:45 PM

If it requires a FAQ rule, it's already broken :lol: OK, then, put it in and we can see if it's necessary or not (it's not like we can't remove it in a later version if needed)... making such a setting be taken care of is as simple as updating Load.php to check for !empty($settings['postmod_rules']) || !empty($settings['postmod_override']) or whatever you want to call it.

.....................
.......I don't really want to change your stuff :^^;:
Wouldn't feel comfortable doing so.
I can only suggest what I feel would be best.

Quote

We could certainly have a link to the moderation filters area from there. I don't like the idea of just configuring an option directly from the menu though.

I don't think I said that...?
Oh, possible re-ordering of the menus: (I'm translating from French to English from memory)
Features & Settings > Settings, Pretty URLs, Anti-spam
Moderation > Settings (currently 'Moderation' in 'Security & Moderation'), Moderation filters, and maybe a link to add a filter directly?

That would save us an extra entry... No?

Quote

There is, of sorts, an approval queue, yes. It's a table with a single column, id_msg. We don't track topics, only the messages themselves.

Hmm, I'm looking into it...
Topics have unapproved posts.
Boards have unapproved topics and unapproved posts.
I can't find any global setting with unapproved posts, contrary to what I thought... :-/
Only an unapprovedMembers variable.
It would seem to me that unapprovedTopics and unapprovedPosts variables would be good things to have, if only to make the queries faster.

Basically, I thought that we had unapproved_posts somewhere, so it was easy thinking: because a topic is a post, if there are no unapproved posts, then there are no unapproved topics, thus we can skip the test entirely.

Quote

Hmm, there's actually nowhere in the system to be able to activate or deactivate a filter. I guess one can be added, though.

On your time and your own terms, of course.

Quote

Quote
Then I think it should be 'acknowledged' at the very least, for instance in the rule settings, instead of 'Posting in...', have something like 'Creating new topic in...' or 'Sending new post in...'?
I guess. It's an extra string, but that's no biggie, of course.

That would be swell.
(And no, I don't particularly like to give you more work to do... I'm busy on my own things, too :P)

Quote

They're pretty nice, just I'd never thought of them before. On the subject of toggles, note that slideToggle and toggle do behave differently as far as forcing a state goes (slideToggle(false) does not do the same overall thing toggle(false) does)

Sure, and this just reminds me that maybe I should have done something else instead of simplifying your JS code to use toggle(boolean)... :^^;:

Quote

Yes. Query conditions are evaluated much as they are in PHP, from left to right with AND/OR working much the same way. One thing... the order that fields are used in conditions is normally supposed to be the same order that the components of a primary/other key are supposed to be, but it's probable they fixed that limitation some time ago.

Always good to know!

Quote

Ugh. My understanding was that if postmod isn't active, the checks shouldn't be performed. Anything contrary to that is a bug, especially since disabling postmod forced everything to be approved anyway. (It's not like us where clearing the rules leaves things unapproved!)

So... Shall we change these to use postmod_active all the time?
Heck... Maybe we could have a {query_see_message} as well. Why not? It'd be simpler -- just the 'approved' test. Although sometimes the tables have a different alias from 'm'...

Quote

Oh yes. And it's not directly solvable just by doing that either, e.g. cases of XSS injection attempts get foiled here.

Why XSS? If we're careful to replace 039 with a quoted single quote right before insertion, it shouldn't be a problem...?

Quote

I'm on the fence about that. Private messages are not private in reality, they are merely personal. Though the core doesn't allow the admin to access it, it also doesn't do anything to prevent it (e.g. obfuscation of the data)

Yes, and thoughts and topics, when set to a privacy of 'author', are not meant to be published. And thus, should be treated the same way as PMs, in my opinion. Unlike an unapproved post, which requires an admin to read them before they're available to everyone.

I mean, admins can't access anyone else's drafts either, can they...?

Quote

Sure it would still be run, but the table it's joining to would be similarly small, so you'd just get an empty column coming back. If the table's small enough to be in memory it's going to be fast.

But how could it be faster than a subselect that, first, doesn't always get executed (yeah, we could apply the same stuff to the left join, but it'd be quite tiresome), and second, uses the same secondary table so should effectively be as fast as the join...?

Quote

To be fair, though, those posts take less mental effort to do. They're also, typically, a *lot* shorter than my posts here. Besides, we're at the stage now where I'm doing a little bit of positive marketing without having to deal with "Post here and... and I'll fucking spank you"

I'm just surprised nobody mentioned that particular forum in here...
(Oh, and one thing you shouldn't mention to me is Kevin Smith. I stopped watching Comic Book Men #1 after 10 minutes, it was felt so... unnatural, scripted and just generally not funny and uninteresting. All of that in only 10 minutes, when you usually pack all of your good stuff into the first few minutes to catch the viewer's attention. I had high hopes. :-/

Quote

Quote
Of course, I *suppose* you thought of that because of Wedge.org's current implementation -- you're thinking that it'd be simpler to just give 'View thought replies' permissions to Friends, and 'View thoughts' permissions to everyone else... Right?
Correct. That's how it is here and that seemed perfectly workable to me ;)

Well, I don't know... I'd like external opinions, once again. Personally I think it's something that can be emulated by putting a privacy of 'groups' and an ID matching our membergroups, too. I'd like everyone to be able to determine whether their answers will be private or public, etc...

Oh, my. I just realized a thought privacy setting that SHOULD be mandatory in Wedge. "Me and the recipient", or something. Just like a mini-PM... And replying to such a thought would automatically set it as private, too.
Hmm, maybe it could be set within the 'author' privacy setting. i.e. if you reply another thought but set it to 'author', what good is it...? If it's just to say "Die, die sucker!", it's not very smart...

Quote

The thing is, privacy controls are wonderful - but they're also complex, no matter how you do them, unless your interface is totally geared to it - which is why G+ got it quite right,

I don't know about G+'s privacy features, I never actually used the thing (in spite of my account over there.)
I just know that Facebook's privacy settings are more extensive now than they used to be...

Quote

If I don't care whether people can see it, I'll post it as a thought. If I do care who can see it, I'll post it in the relevant board.

To each their own ;)

Arantor · « Reply #**114**, on February 26th, 2012, 03:58 PM »

Quote

Looks like you didn't compile the list I asked you to do... I know, I know, it's annoying for you too

There's an awful lot here >_> I'm actually at the point where I don't know where to start with compiling such a list.

Quote

Wouldn't feel comfortable doing so.

That's how I feel about working with Aeva's code a lot of the time, actually. But honestly, if it doesn't work for you, change it. That's the beauty of stuff like this - nothing's set in stone and as such it's fluid and can be adjusted and improved. I'm not convinced that it'll be perfect first time - and nor should it. If you never make mistakes, you never learn anything!

Quote

I don't think I said that...?

In that case I wasn't clear on what you were suggesting, because I thought you meant the master admin tab in the main menu, rather than a sub menu.

Quote

Oh, possible re-ordering of the menus: (I'm translating from French to English from memory)
Features & Settings > Settings, Pretty URLs, Anti-spam
Moderation > Settings (currently 'Moderation' in 'Security & Moderation'), Moderation filters, and maybe a link to add a filter directly?

So... (I just find it easier to visualise it in a real hierarchy)

Configuration
Features and Settings
General
Pretty URLs
Anti-Spam
Moderation
Settings
Moderation Filters
Add a new filter rule

Hm. I'd rather bring anti-spam under the moderation menu, really. It's really closer to that than to general configuration. In which case we're really talking about:

Configuration
Features and Settings
General
Pretty URLs
Moderation
Anti-Spam
Warnings
Settings
Moderation Filters
Add a new filter rule

It doesn't save us anything and has a byproduct of pushing things to side entries - I deliberately made Mod Filters a top level item, much as I would do if Post Moderation were its own item (and not configured through mod filters), simply because it's a task of configuration that needs to be prominent - it's forum wide and not subtle.

Quote

I have this fear all of a sudden... If t.approved=0, then m.approved=0 where m.id_msg=t.id_first_msg...

When a topic is moderated, the first post is also moderated.

Quote

It means we have to add inner joins on every single friggin' table.

I'm not seeing the problem? If you're validating topic access, the topic's approved state is all that matters - when the topic is approved, the first post is also updated.[1]

Oh. Wait a minute, now I do: it won't apply to messages after the first one.

Actually, though, that's still not a problem. When would you ever make a query against messages when you haven't already checked the topic in some fashion? Be that directly yourself or less directly by way of loadBoard()...

Quote

It would seem to me that unapprovedTopics and unapprovedPosts variables would be good things to have, if only to make the queries faster.

Basically, I thought that we had unapproved_posts somewhere, so it was easy thinking: because a topic is a post, if there are no unapproved posts, then there are no unapproved topics, thus we can skip the test entirely.

It would make a difference, certainly. It's just a little housekeeping that's needed is all.

Quote

On your time and your own terms, of course.

I'll look into it, it's just a bit complicated, heh, and there are things I'd rather do first. That said, right now only you and I have seen this subsystem which means our opinions are a touch polarised on it. What I'd suggest is that we let people play with it and see what works for them.

Quote

And no, I don't particularly like to give you more work to do... I'm busy on my own things, too

I'll look at it shortly, as part of a few other things I'm doing today.

Quote

Sure, and this just reminds me that maybe I should have done something else instead of simplifying your JS code to use toggle(boolean)...

Hey, it was a useful thing to discover, I fixed up an otherwise broken UI because of it :)

Quote

So... Shall we change these to use postmod_active all the time?
Heck... Maybe we could have a {query_see_message} as well. Why not? It'd be simpler -- just the 'approved' test. Although sometimes the tables have a different alias from 'm'...

I'd suggest leaving it as is for now - there are people who aren't going to use moderation filters, no sense penalising them. As far as tables go, there are plenty of times m isn't the table alias (message index is the one that really comes to mind) so it's not like we can directly make it easy that way, sadly.

Quote

Why XSS? If we're careful to replace 039 with a quoted single quote right before insertion, it shouldn't be a problem...?

There isn't a *huge* risk from XSS, because it sort of implies weaknesses elsewhere that have to be compromised too, but in the case I'm thinking of, ' can be used instead of " for quoting attributes.

Quote

Yes, and thoughts and topics, when set to a privacy of 'author', are not meant to be published. And thus, should be treated the same way as PMs, in my opinion. Unlike an unapproved post, which requires an admin to read them before they're available to everyone.

I mean, admins can't access anyone else's drafts either, can they...?

Yes, that's a valid POV (and no, drafts can't be accessed by anyone other than the author - but just as with PMs, admins can still read them in the DB... there are no other protections made in that respect, so the software doesn't enable but it doesn't proactively prevent it either)

Quote

But how could it be faster than a subselect that, first, doesn't always get executed (yeah, we could apply the same stuff to the left join, but it'd be quite tiresome), and second, uses the same secondary table so should effectively be as fast as the join...?

I wasn't really debating subselect vs join, the real performance is whether the table's able to be kept in memory or not.

Quote

I'm just surprised nobody mentioned that particular forum in here...

I guess it just never came up. (And re Kevin Smith, his earlier stuff is far funnier than his latest stuff, though his later stuff is meant to be less comedic, I guess.)

Quote

Hmm, maybe it could be set within the 'author' privacy setting. i.e. if you reply another thought but set it to 'author', what good is it...? If it's just to say "Die, die sucker!", it's not very smart...

This needs its own topic.

Quote

I don't know about G+'s privacy features, I never actually used the thing (in spite of my account over there.)
I just know that Facebook's privacy settings are more extensive now than they used to be...

Essentially you create groups as you see fit and you can share items to none, one or more groups.

1.	Whether it's approved from the view-unapproved-topics page, or from approving the first message directly, it doesn't matter which, both are updated.

Nao · « Reply #**115**, on February 26th, 2012, 05:28 PM »

Okay, there's a lot to be said and I'll answer more thoroughly later. Right now I'm in the middle of Dae Jang Geum and the Highest Kitchen Court Lady got elected but the other High Court Ladies went ahead and decided to tell the King's Mother that they won't accept her orders because they're faithful to the rival family of corrupts and the previous Highest Kitchen Court Lady just got a heart attack and the preview showed that she'll be dead by the next episode so the new Highest Kitchen Court Lady won't have any support and I got spoiled and she'll be wrongly accused of treason against the king and she'll be executed so how's her protégée the heroine gonna cope with that, what with being sent in exile or what?[1]

So, now you'll certainly understand that with such shitty soap opera crap, I'm totally hooked and won't look into this all for a while... :lol:

No, seriously, it's a great show. It's just that it's on an extremely cheap budget/production values that aren't worthy of the quality of its story. If you ever watched 'Lady Vengeance' (by the director of smash hit Oldboy), they both share the same main actress.

Anyway, jokes aside... What I'm thinking for now, is that I'll be creating extra tables and use these. In the end it's gonna make things easier for everyone, and we'll be able to go for a Google+ experience if need be, with multiple contact lists and such. (I'm thinking, "all contact" could be represented by an ID of '0' in the table. It would save having to manually enter an entry for each contact list. I'll still have to find a way to quickly find your contact lists before I start matching them in the topic_privacy table of course... Headaches ahead, but if the big guys do it, I'll do it too.)

1.	I've got the perfect English name for the show: Revenge is a meal best served with kimchi.

Arantor · « Reply #**117**, on February 29th, 2012, 11:52 AM »

I haven't digested everything here, but wanted to catch up on the most important points (to me at least)

Quote

Look at the only query with a m.approved test. It doesn't test for topic privacy. Then, the subsequent query does a topic join but doesn't have query_see_topic, either. In the end -- it's broken.

Yup, it certainly is. It needs to have query_see_topic somewhere, ideally the earlier the better.

Quote

a m.approved test is very close to a t.approved test because in SMF, an unapproved topic can't hold approved posts. I think

Ah, but it can. This is one of the many foibles of the system. If you have a topic that is unapproved, the owner and moderators/approvers can see it. Should a moderator/approver reply to it (e.g. in response to the opening post, as per SMF Showcase board), that post will be approved, but the topic as a whole and its opening post will both be marked unapproved.

Quote

Would be fixable I think -- if anything, by renaming these custom aliases to 'm', and renaming the other 'm' to something else...

That's the thing, when you have two instances of the messages table aliased, it's normally because both the first and last message in the topic are being referenced, (e.g. message index pulls both the first post for the subject and topic starter, and the last post for the last poster's name and post time) and both of those could be separately approved or not.

Quote

To me, single quotes and double quotes can always be used in a field. It's just when *communicating* with that field that one has to be careful... i.e. you have to escape quotes at the last moment when inserting data. But that's really the ONLY moment I can think of where we absolutely NEED to escape stuff... Unlike a 039 that has no particular purpose in a table row.

The point is, while I can't bring any examples immediately to mind, it's possible that someone can find a combination of ' and " that would allow them to escape out of the usual protective layers, so that malicious links or onclicks could be added.

Nao · « Reply #**118**, on March 8th, 2012, 03:24 PM »

Quote from Arantor on February 29th, 2012, 11:52 AM

I haven't digested everything here, but wanted to catch up on the most important points (to me at least)

Ready to digest, or giving up? :P

Quote

Quote
Look at the only query with a m.approved test. It doesn't test for topic privacy. Then, the subsequent query does a topic join but doesn't have query_see_topic, either. In the end -- it's broken.
Yup, it certainly is. It needs to have query_see_topic somewhere, ideally the earlier the better.

Or query_see_message when no topic join is available... I don't really see a better way of doing it than forcibly adding a subselect on the topic.

Quote

Ah, but it can. This is one of the many foibles of the system. If you have a topic that is unapproved, the owner and moderators/approvers can see it. Should a moderator/approver reply to it (e.g. in response to the opening post, as per SMF Showcase board), that post will be approved, but the topic as a whole and its opening post will both be marked unapproved.

So, technically, anyone will be able to read their post in the Recent Posts area, but not click on it to see it in context...?

Quote

The point is, while I can't bring any examples immediately to mind, it's possible that someone can find a combination of ' and " that would allow them to escape out of the usual protective layers, so that malicious links or onclicks could be added.

I really don't see how.

So... About topic privacy, then. Back on this... And I'm scared. Really scared.

Considering that topic privacy can be given to either of these (one or more!):
- everyone
- only registered members
- only one or more membergroups
- only one or more contact lists
- only one or more members

The query_see_topic can quickly become quite a behemoth...
Pseudo-code.

Code: [Select]

privacy = everyone
OR (privacy = members)
OR (
	privacy = contacts
	AND t.id_member_started != 0
	AND FIND_IN_SET(<user_id>, (SELECT buddy_list FROM members WHERE id_member = t.id_member_started))
)

This is what we have right now...
What customization will give:

Code: [Select]

privacy = everyone
OR (privacy = no_guests)
OR (
	privacy = contacts
	AND (SELECT id_member FROM contact_lists WHERE id_contacts = <privacy_id> AND id_member = <user_id>) = <user_id>)
)
OR (
	privacy = groups
	AND (<privacy_id> IN (<user_membergroup_list>))
)
OR (
	privacy = members
	AND (<user_id> = <privacy_id>)
)

Now, that looks like an acceptable price to pay... Only, this query is no longer done on the topic table itself, but as a JOIN on the privacy table. Meaning that, first of all, we need to add a row for every topic (saying 'privacy = everyone' by default), even if everyone can view it. Or we have to use a has_privacy field on the topic table and use the above code in a subselect instead of doing a join. Then, it's a BIT annoying to do a subselect on every contact list test, maybe we should also maintain a list of contacts in the member table -- maybe even two lists: the contact lists you own, and the contact lists you're in. (Heck, at that point, maybe we don't even need a contact list table... Then again we'd have to have a huge field for the contact lists you're in... If only because I suppose you could be in multiple contact lists *per member*...)

Also, what about if I'm found out to be a positive for topic privacy as soon as the first item in the privacy list? Will the JOIN keep going through the table? Would a LIMIT 1 be enough to stop it from doing that? But then we need a subselect, right...?

So much fun. And we get to do this for both topic and thought privacy... *And* write the UI later as well... Eh eh.

Arantor · « Reply #**119**, on March 8th, 2012, 03:31 PM »

Quote

So, technically, anyone will be able to read their post in the Recent Posts area, but not click on it to see it in context...?

Wasn't there a t.approved = 1 test there as well? I don't remember. But it wouldn't surprise me if it were buggy.

Quote

Also, what about if I'm found out to be a positive for topic privacy as soon as the first item in the privacy list? Will the JOIN keep going through the table? Would a LIMIT 1 be enough to stop it from doing that? But then we need a subselect, right...?

Would need benchmarking and query plans to be sure, but AFAIK, if the first branch is matched, the rest aren't if a given row would be returned in the OR case (if x OR y causes a row to be returned, it will be returned as soon as x is matched, or if x isn't matched, then return if y is matched)

Quote

So much fun. And we get to do this for both topic and thought privacy... *And* write the UI later as well... Eh eh.

Yup.

Quote

Or query_see_message when no topic join is available... I don't really see a better way of doing it than forcibly adding a subselect on the topic.

There isn't a better way of doing it. I remember running into that a touch with SimpleDesk where I had {query_see_ticket} and ended up adding the ticket when it wasn't strictly necessary.

Quote

Ready to digest, or giving up?

I've spent the last 24 hours trying to make sense of FTP. I could not conceive of a more backwards-ass specification if I *tried*, and to a degree I've just been thinking about everything else rather than focusing on this >_> I keep getting feelings of having so much to do, you know?

Wedge

Home

Login

Register

Would you like to have topic privacy options in Wedge?

Arantor

Re: Privacy options

Nao

Re: Privacy options

Arantor

Re: Privacy options

Nao

Re: Privacy options

Arantor

Re: Privacy options

Nao

Re: Privacy options

Arantor

Re: Privacy options

Nao

Re: Privacy options

Re: Privacy options

Arantor

Re: Privacy options

Nao

Re: Privacy options

Re: Privacy options

Arantor

Re: Privacy options

Nao

Re: Privacy options

Arantor

Re: Privacy options