Kevin Carwile

@Apfelstrudel,

The comments and reviews on collabs is not "group content". It is for members on the main site to comment or review the collab.

When you set up the collab category, you choose which apps from the main site that can be used inside the collab (such as forums). When collab/group members use those apps inside the group, permissions can be set as to who can view that content. That is how you achieve your privacy.

The "private listing" setting in the collab category hides closed/invite-only collabs from public listing within the category.

Not with rules. What you are describing is not any sort of workflow automation, it is theme switching. To do what you are describing will take modifications that operate on the theme layer. Rules provides automation tools for manipulating the data processing layer.

There is a Rules Lite version of the application in the marketplace which is FREE. It's an excellent way to push buttons before you take any plunges.

Yes to everything you said.

It works on the ECA (Events, Conditions, Actions) design principle. So I guess you could say conditions is its middle name.

Ya, I understand. The complete set of ECA's that you'll need to fit those needs aren't far away. Hang in there.

I like the way you're stretching the software out. Keep up the good work!

Just by viewing a collab you become a member?

Ok, well... as you said, that should be possible with rules after I am able to add those actions to the ECA set that ships with GC. I only added the events to the latest release due to time constraint. Actions will be included in the next.

But you realize that if you set the group membership setting of the collab to be open without approval, anybody can join the collab just by clicking the join button. At that point, they automatically become an active member.

​Currently, rules only includes form fields to edit integers, text fields, and yes/no switches. I will be expanding the available form options to include node selectors, member selectors, and editors. When that is complete, you will be able to accomplish your goal as you had mentioned using rules.

If it works with IPS4 then it works with GC. No hacking required.

​If you're asking how GC remembers what collaboration that each forum is owned by... there is a column added to the forums table which stores the ID of the collab.

I dont think there is an "approve posts" moderator permission in core. It's coupled with the moderator ability to unhide posts.

That restriction is a forum based setting. If that setting is used by a collab leader for a collab forum, it stands to reason that posts from outside the group should not count toward that restriction total. Simply remove the restriction for forums inside your collab to bypass the issue.

If you do not want members who have not posted at least 3 content items to be able to join collabs, then set up a group promotion for members to happen after 3 posts which moves them into a member group who has permission to join collabs.

The 1 post is in reference to their post count within the group. The 268 is a reference to their primary site post count.

Its as solid as hard foam dipped in laminate and then put in the oven for 10 minutes. You'll be ok with installing it.

BTW, what is a file depot change?

​I'm exploring options for including custom profile fields into rules ECA's, but at the moment, it is a very closed system and needs to be softened up by IPS a little bit for better 3rd party integrations.

What else are you using this custom Yes/No profile field for? You could create a custom Yes/No data field in rules and attach it to members and then you will have full rules access to check and update that field. In which case you would have a rule that looks like this:

• Event: Member profile is updated
• Conditions:
  • Member is in a certain member group
  • Truth value (check the Yes/No custom field for user)
• Action: Update custom data for Yes/No field

• ​Event: Output is being sent to browser
• Conditions:
  • User is in a specific member group
  • Custom PHP Code (check if user is trying to add a new pages record):

    $page = \IPS\Request::i();
    $database_id = 1; // id of pages database
    return ( 
        $page->app          == 'cms' and 
        $page->module       == 'pages' and 
        $page->controller   == 'page' and
        $page->do           == 'form' and
        $page->d            == $database_id
    );

  • Custom PHP Code (check if user has already added a certain amount of records):

    $database_id = 1; // id of pages database
    $threshold = 10;
    $content_count = \IPS\Db::i()->select( 'COUNT(*)', 'cms_custom_database_' . $database_id, array( 'member_id=?', \IPS\Member::loggedIn()->member_id ) )->first();
    
    return $content_count >= $threshold;

     

• Actions:
  • Redirect to another url (maybe another page that explains why they can't add more content
     

     

@Police Community

Interesting predicament. I may need to enable the source editor on the wysiwyg for you to setup the link. My guess is that the tokens are being url encoded when you enter them as a url component, and therefore not being replaced properly.

I'll look into this.

Its actually built into the collab homepage display template. If there are more than 2 forums, it switches to grid layout to display forums.

I'd be more than happy to help you out.

1. On the first rule, it sounds like you're using the correct event and have the action set up correctly, but you're having trouble with the condition portion of your rule.

• Event: Member profile is updated
• Condition: Check array value ( You want to check the array of profile fields that have changed for the "pp_main_photo" key )
• Action: Create new topic

rule-when-member-photo-is-updated.xml

2. What you want to do in a situation like this is to create a custom action which you will use to create the topic. You will then schedule this custom action to happen in 30 days. That custom action then becomes a new event in the system that you can attach additional rules to so that you can check conditions when that action is invoked at the scheduled time, and take additional actions at that time such as either creating the topic if the member has indeed been inactive for the 30 days prior, or if not, rescheduling the custom action to happen again in another week or so which will repeat the process indefinitely.

As for the scheduling key portion of the equation, whenever you schedule an action, custom or not, you can enter a "scheduling key" for the action which will give it a unique identity so that you can operate on it later (such as delete it, or re-schedule it). When you use a scheduling key, you usually want to include a token of some sort from the event that will make it unique to a certain aspect of the event, such as the member id of the user it is being scheduled for. So the scheduling key for your use would look something like this:

create inactive topic for member:[member:member_id]

So when you schedule an action again with that same key, the old one is removed and only the new one remains (hence re-scheduling).

Like you said.

This sounds like a job for...  

da tada da ta da... Rules! 

But I havent added the ECA's into GC yet. So there will be a short wait on that. But its coming for sure.

What about the administration header? I'm confused at what you're describing.

I agree. However this behavior is not a function of the GC app, its built into the Forums app. I'lI see if there is anything I can do here to relieve some tension but generally speaking, GC does not modify the inner workings of apps... it just controls access.

​The VNC filters that GC adds filters out only content that the user does not have permission to view. So if they aren't a part of a collab, but they still have permission to view the content, then it will be included in the VNC list.

​Agreed. This thought has crossed my mind as well. I believe this may help relieve some of the VNC frustrations outlined by @Police Community also.

​That may be feasable. I'll have to look into it.

​I will build some API methods into the application that you can use to query content from a specific collab.

I hate having to say no.... but no.

Yes, I agree fully. The commerce expansion has not been forgotten.

But it is going to be the largest expansion pack of them all as there is much more than what has already been listed for it to be a complete package.

First I need to get out a much smaller expansion to cover the core IPS downloads app, and then I will start on the ECA's for the commerce app.

And at some point in between all of this, I need to get some documentation written on how other developers can include their own ECA's in their apps using rules extensions in the developer center. My goal and hope is that all apps will be customizable with rules at some point.

1. ​True. Copy makes a clone of the structure, and not the content.
2. True. The structure is re-allocated to the collaboration and therefore the content goes with it.
3. For a move, no ID's are changed. In fact, you're not really moving anything except authority over the content.
4. No. GC exercises no control over the language selection options for users.