Kevin Carwile

What tables dont have indexes? Which queries are slow?

What version of IPS4?

Try creating a custom action to check for the sold prefix on the topic and close it, and then trigger that custom action from your rule when a "topic has been created or updated". And make sure to set the action execution to the "end of page load" setting. I believe the problem you are having is because of a timing nuance. When the topic is created/updated with new tags, then the event actually happens before the tags are saved to the topic in core processing.

No. But what have you got?

Yes, it will work.

That's not so easy. But I'll give you the solution anyway in case you are the adventurous type. The attachments aren't actually "attached" until after the content created/updated events have happened (internal ips workflow thing). So you can't check the condition on a rule attached directly to one of those events because the attachment won't actually have been claimed yet. Also, there is no stock condition to check if a topic or post has an attachment, so it would require a custom php snippet to do that. So... for the solution: You need to first create a custom action which you will trigger from a rule when the content is created/updated and set the action execution to wait until the end of the page load so that the "attachment" can be processed before your custom action is actually fired. And then you would check the condition in your custom action rule. The custom php code portion of the condition would look like this (this means you need to add an argument to your custom action called "Content", which would either be a content item class or a content comment class, and would make $content available to your custom php code): /** * If content being checked is a topic/item, check if any post has an attachment */ if ( $content instanceof \IPS\Content\Item ) { $locationKey = $content::$application . '_' . ucfirst( $content::$module ); return (bool) \IPS\Db::i()->select( 'COUNT(*)', 'core_attachments_map', array( 'location_key=? AND id1=?', $locationKey, $content->activeid ) )->first(); } /** * If content being checked is a post, see if it has an attachment */ else if ( $content instanceof \IPS\Content\Comment ) { $item = $content->item(); $locationKey = $item::$application . '_' . ucfirst( $item::$module ); return (bool) \IPS\Db::i()->select( 'COUNT(*)', 'core_attachments_map', array( 'location_key=? AND id1=? AND id2=?', $locationKey, $item->activeid, $content->activeid ) )->first(); } return FALSE;

I believe the member re-engagement example does this.

You could set up a custom action to roll together the group change and welcome PM (with beta key) into one function. Add a member as an argument to the custom action and also add a string value to the custom action to accept the beta key. When you are adding the standard PM action to your custom action rule, the beta key passed in will be available as a token value to insert into your message. Then all you have to do is trigger your new custom action to perform the group change and send the PM with beta key. When configuring the beta key to send to your custom action, you would choose php code as the source and pull a new beta key from a list somewhere as you stated. That part would be up to you to work out. But lets say that you have a comma seperated list of keys in a text file... you could do something like: $keys = explode( ',', file_get_contents( 'keysfile.txt' ); $key = array_shift($keys); file_put_contents( 'keysfile.txt', implode( ',', $keys ); return $key;

That brings up a few questions. Is it one key per member and then it is not to be used again? How would you know who has what key? Does it even matter?

Thats because women dont think logically. I'm totally just kidding.... but its true. J/K

Rules only does what you tell it to do.

If it matches where you dont want it to match, then you are missing a condition. If you don't want it to match a particular case, you need to add a condition which will cause it not to match. For example, why not add another condition to the 25 posts award which checks if the posts are less than 100. Did you know that you can export rules and post them which will allow others to import and inspect exactly what you have built? You can also choose the "Rule Overview" option from the rule dropdown menu to get a copy/paste generated overview of your rule, which is also much more useful to understand what your rule configuration looks like in a nutshell.

If it matches where you dont want it to match, then you are missing a condition. If you don't want it to match a particular case, you need to add a condition which will cause it not to match. For example, why not add another condition to the 25 posts award which checks if the posts are less than 100. Did you know that you can export rules and post them which will allow others to import and inspect exactly what you have built? You can also choose the "Rule Overview" option from the rule dropdown menu to get a copy/paste generated overview of your rule, which is also much more useful to understand what your rule configuration looks like in a nutshell.

ipsguru.net/rules

http://ipsguru.net/rules/support The joined date had a bug which was fixed in recent versions. You update rules for the fix. Once you have done that, your condition should work as expected.

I see how this is going to go. I was simply offering to do the legwork to make this app more flexible via rules. I'm not interested if any question you recieve for your app which has the word "rules" in it is simply going to get referred back to me. Never mind.

So if you are trying to check the forum that the topic was moved OUT OF instead of IN TO, then its forum check is not going to work because that will be checking the forum that it is currently in, which would be the forum it was moved to. The old forum that it was in is available as an event argument, but I'm realizing now that a valuable condition is missing from rules core. There is currently no way to check if "a forum is a specific forum" outside of using php code to do the test.

So if you are trying to check the forum that the topic was moved OUT OF instead of IN TO, then its forum check is not going to work because that will be checking the forum that it is currently in, which would be the forum it was moved to. The old forum that it was in is available as an event argument, but I'm realizing now that a valuable condition is missing from rules core. There is currently no way to check if "a forum is a specific forum" outside of using php code to do the test.

You know what... I see what you did. You chose the event for ANY content item is moved instead of a topic is moved. So basically your content item in the event could be anything from a topic to a blog or a calendar event, etc. So rules wont let you select it as a topic to check because it may not even actually be a topic. Change your event to be more specific, such as "topic is moved", and then rules will let you use it in your forums condition.

You see the drop down that says "manual configuration"? Change that.

The rule is run for whenever a topic is moved... so that would mean all topics. And you are trying to set a condition that it is not in a certain forum. Ok. You added the condition to check if the topic is not in a certain forum. So far so good. Then you confused yourself by thinking you need to check all topics in that condition... but really you should be just checking the topic which was moved. That is why you select the topic from the event arguments list. Because that is the topic you want to check. You dont want to check if ALL topics on your site are in a certain forum. Just the one which was moved.

* is not a wildcard. That means the field is required. You need to change from manual configuration of the topic and choose the topic from the event arguments.

It would check all member groups including secondary groups. The condition uses the IPS core $member->inGroup() method to check for groups, which itself uses all member groups.

There is a point release made this morning to fix that issue. 1.3.10.1