Kevin Carwile

Thanks doc.

Just PM me details to access the ACP of your site and I can take care of that for you.

Good point. I'll add the warn level into the member attributes in a future version. For now, you could do it by creating a "number value" condition and for one of the numbers to compare choose "PHP Code" as the source and return the member's warn level. I.E: //<?php return $member->warn_level;

It's not a problem. You just set the permission on the container to allow collab guests to see the content and they can still get their follow notifications. If you set the permission on the container to allow guests to post, they can still participate without needing a membership. If you set the membership join mode of the collab to automatically accept new members without approval, members can choose to join or not. You could even do what @Police Community has done with his board and create a rule that automatically joins members to the collab when they view the collab homepage, since GC has built in ECA's for the Rules application. Automatically joining members on content move is going to be problematic anyway, such as if the collab category has a maximum collab membership set to a smaller number than the number of participants in the content being moved.

Seems pretty feasable and useful. But what happens when a member has chosen a custom site theme and a collab owner has chosen a different theme for the collab?

@kar3n2, Its officially stable. Have fun!

Yes. Those titles are saved in the language system so you can customize it from there. Search for languagr key: 'block_latestCollabs' and 'block_featuredCollabs'

Template: collab/front/components/nodeList The $grid variable in the template can be adjusted to determine the threshold at which the display switches to grid view.

It works with pages. Just create a database that uses categories, add it to a page, and enable it for use in collaborations in your collab category setup.

The problem with the execution of the scheduled action is fixed in version 1.1.4 (which was just uploaded to the marketplace a few minutes ago). It appears that the login event is triggered by the ajax login and also again when the page reloads as a result of the login. But this is not a bug in rules, it's a behavior of the core IPS suite. I'm not sure if IPS would consider it a bug or not. With that said, this issue is easily mitigated in the rule by scheduling the action to send the private message and using a scheduling keyphrase. If the event is fired twice in a row by the framework, then the second scheduling of the action will simply overwrite the first, which is the whole purpose of a scheduling keyphrase. I noticed the rule you posted does not use a scheduling key. This is probably because I exported it to the starter rule pack before I fixed the bug which was preventing the scheduling key from being exported with rules. I'll update the starter rule pack in the marketplace to include an example of the scheduling key. Essentially, you want to use a scheduling keyphrase such as: inactivity pm message for member:[member:id]Each member will then only be able to have one action scheduled with that keyphrase at any given time.

GC enables the use of other apps in collaborative mode. Without any other apps, you would be able to create collaborations, comment, rate, and manage memberships... however there would be no other apps in the system that could be used for collaborative use (such as forums).

You could do this but it would be up to you to determine which other files would be considered similar and form the email dynamically using the code fearures in rules.

GC already hooks in to the core methods in the framework to limit content in that way. So if you have a sidebar widget placed that shows the most recent topics for example, those topics will only be the most recent for the collab being viewed. Are you saying that its not behaving that way on your site? Unless the widget is bypassing core methodology to pull its data, this should work for any widget. Similarly, a recent topics widget on the main site (not in a collab) should show topics from the main site forums and also any topics in collabs that the user has permission to view.

​The titles of blocks are changed through the language system. Search for "block_featuredCollabs", and "block_latestCollabs". ​There is a moderator permission on the moderators configuration form inside the ACP. Members -> Moderators -> {Edit moderator/group} -> Collab Management tab Enable the option: "Unrestricted by collab permissions ".

​You'll also need to delete the action in your rule and re-create it.

Good idea. I'm making a note right now.

What does that mean?

When configuring the post author in the action, select "manual configuration" for the comment author instead of choosing event data. You can simply type the name of your bot account in as the comment author.

​My head just spun around on my shoulders. I have no idea what kind of rule you configured. PM me regarding this issue and include an exported version of your rule so I can check out what you've got going on.

@GrooveOnBeat, The EX2 error turned out to be a bug. It's been corrected in the latest release. Go grab that. As far as the conditions to check if the member has logged in only 1 time, there is not a login counter built into IPS core that you can check with a condition, so in order to accomplish this you will have to create your own counter. That is why the configuration gets a little more complicated, but just by a little. Add a custom "integer" data field attached to member via rules ACPCreate a rule that is triggered when a member logs in. In the rule, add an action that increments the custom data field you created in step 1.Then in your other rule which does the redirect, you can check this custom data field to check if the counter is under your threshold of logins.

​Instead of manual configuration to select individual members, choose PHP Code and select all members from a particular group: $group_id = 1; // Change to ID of member group to select return iterator_to_array( \IPS\Db::i()->select( 'member_id', 'core_members', array( 'member_group_id=?', $group_id ) ) );

Not sure what you mean here. The action will redirect to any url you give it. The way I set that rule up is pretty basic. It redirects on login if the member was registered within the last 24 hours... regardless of the number of times they have logged in. If you want to only redirect one time and one time only, you will need a slightly more advanced rule which tracks if the redirect has been done for them yet.​ Yeah. Each rule has the enable/disable button on it. Just click it to enable/disable.

​Rule: Redirect new members to edit profile Event: Member logged in to systemConditions:Member attribute values (Member has joined within the last 24 hours)Actions:Redirect to another page (Redirect to the members profile edit page) redirect-new-members-to-edit-profile.xml

You don't need anything fancy to accomplish that. Just use these settings: change-author-group-on-topic-move.xml

​The titles of the blocks are customizable through the language editor.