How do I change the default set of Group permissions for Owners, Managers and Members

Changing the default templates is only available in 12.0.  You would go to administration->Groups and select Membership Types to deal with group default roles   or Global Permissions for site roles.

This would indeed work for me. Thank you, just what the doctor ordered. The v12 path is Administration-->Groups-->Membership Types--> {select Privacy Setting like Private Unlisted}-->{select Owner}, modify the settings and save.

I like the choice to select it by privacy setting as this is indeed related to those types. It is a bit more work but I get it. Nice.

Thanks Patrick M. 

Our customer is at v11. What is the route to go for v11? A custom plugin?

You can trigger from the Group.AfterCreate event and set Application permissions for the group for any role (site or group). To do this, just specify the GroupId in the options of the core_v3_permission.Set call. Any applications created after permissions at the group level have been set will inherit their initial permissions from the Group's configuration.

Thanks Steven. What's the script API call to get the default application permissions at the group level? I used $core_v3_permission.List and passed in the GroupId..

e.g. $core_v3_permission.List(24, "{% GroupId = 12 }")

(where 24 is the role Id for Members)

But it only returned group-specific permissions like Group_CreateWiki.

You can check the default permissions with an ApplicationId in the List call, after creating an application. Default templates only differ by group type and group role, so once you have recorded the defaults, you should be able to just specify the changes you want to make with the Set calls.

Yeah, but if there aren't any applications in the Group just after its creation, there isn't an applicationId to pass in.. unless I'm using the Group's application id? (it's the UK evening, so I'm not on my work PC to check). Sorry for needing so much help here.. the documentation isn't great and I've been really struggling to figure out how it should work.

In general, for setting group permissions from a custom-managed "template" (ie, list of desired changes that you manage), you shouldn't need to list existing permissions of a new group. Once you've generated your list from an existing group set up with the out-of-the-box defaults including applications, then you can apply that list going forward to new groups.

Sorry, you're losing me. If I don't list the existing permissions of a new group, I won't know the PermissionId I'm adjusting via .Set 

E.g.

$core_v3_permission.Set($isAllowed, $roleId, $permissionId, "%{ ApplicationId = $applicationId, GroupId = $groupId }"))

$roleId is fine.. I've got that for 'Member'
$permissionId isn't known (I'd need to list permissions for an application to get this, wouldn't I?)
$applicationId isn't available because no appplications exist in the new group
$groupId is the ID for the new group

I think you then talk about setting up a group somewhere with all the defaults we'd want on a new group.. but how do I take that as the input, and apply the permissions to the new group.

If you've got an example automation or any code it'd be extremely useful. I can post the full solution when we've got this figured out, as I think other people will find this useful too.

PermissionIds are static, and exposed via script extensions for each application, e.g.  core_v2_blogPermissions Script API  , calendar_v1_permissions Script API , etc. (Also for groups: core_v2_groupPermissions Script API ) So you can know ahead of time what permissions would be available for each application, and set them at the group level, which would then be applied as the default for any new applications created in the group. (The reason I mentioned first creating a test group with applications would be to compare your desired permission list against the existing/out-of-the-box default list, to know which permissions need to be added or removed by your customization.)

Drop the ApplicationId portion out of the Set call:

$core_v3_permission.Set($isAllowed, $roleId, $permissionId, "%{ GroupId = $groupId }"))

• $roleId would be the specific Group/Site role Id you want to alter this permission for
• $permissionId would be the static value from one of the provided permissions extensions
• $groupId would be the specific Group you're making this change for

Then, you can confirm by viewing Manage Group > Permissions > Group Roles > Members (or whatever role you are setting for) and checking there to confirm the permission is being set as expected.

Ohhh, that's got it. It didn't occur to me to pass in the permissionId from another application. Great. That works for me.. I can get on with an automation rule to automatically set default application permissions for a newly created group. Thanks for your help Steven, it's been invaluable. 

Happy to help!

Hi Steven Heffner me again Okay, so the automation rule I wrote was looking good.. until I tested it with all the different application types. I'm finding blog doesn't return any permissions using the following script;

## #set($appId = $core_v2_utility.ParseGuid('756b21b3-6b08-44b6-b42e-c19fffc7e6f5')) ## Wiki
#set($appId = $core_v2_utility.ParseGuid('2b8591eb-5285-4281-a7fe-a7eb24d57d88')) ## Blog
$core_v3_permission.List(2550, "%{ ApplicationId = $appId }")

This video shows how I'm looking up the Application Guids and checking the role Id, and that permissions exist, etc.

Hi Steven Heffner me again Okay, so the automation rule I wrote was looking good.. until I tested it with all the different application types. I'm finding blog doesn't return any permissions using the following script;

## #set($appId = $core_v2_utility.ParseGuid('756b21b3-6b08-44b6-b42e-c19fffc7e6f5')) ## Wiki
#set($appId = $core_v2_utility.ParseGuid('2b8591eb-5285-4281-a7fe-a7eb24d57d88')) ## Blog
$core_v3_permission.List(2550, "%{ ApplicationId = $appId }")

This video shows how I'm looking up the Application Guids and checking the role Id, and that permissions exist, etc.

Does the empty response for blog permissions have any warnings or errors?

I noticed you removed all permissions for blogs during the video, does the same issue occur when some permissions are assigned?

Ah yes.. I should have opened up that part of the response in the video so you could see what it had inside.. but in my head, I already knew (from looking before) that it was empty   e.g.

I'd been toggling on/off those permissions as I tested.. at the bottom (not on the recording) Read Blog is enabled, so not all of them were disabled/unassigned.

BTW, this is on v11.1.8.16788.

Hmm, I'm unable to replicate this issue - Can you confirm that the permissions are registered in the database?

SELECT * 
FROM cs_Security_NodeTypePermissions ntp
INNER JOIN cs_Security_Permissions p on p.PermissionId = ntp.PermissionId
WHERE ApplicationTypeId = 'CA0E7C80-8686-4D2F-A5A8-63B9E212E922'

Sure, here you go.. 

Can you confirm the blog is registered in the core Application table?

EXEC te_Content_Application_Get '2b8591eb-5285-4281-a7fe-a7eb24d57d88'

If not, can you provide the steps you took when creating this blog? Was it all through API or did you create it in the UI? Any differences from how you created the other apps?

That query returned no result.

I'd created the blog by hand using the admin panel.. Manage Group > Applications > Add Application.

I've just tried disabling/enabling that blog applications, and edited the permissions, but the SQL still returns no result.

Ok, I'm able to reproduce this behavior now. I'm logging a bug. The issue lies with the timing of creating the blog and then listing permissions. If no core service operation has occurred, then listing permissions can erroneously return an empty list, even though the permissions exist and have been created successfully.

As mentioned, any core service operation will populate the necessary record in the core Applications table. Search Indexing will do it, Activity Story creation (e.g. if a blog post is created that generates an activity story), and many other operations related to content like tags, views, etc. As I mentioned, these permissions do exist and will be properly checked, but they are not returned when listing via the API due to this timing issue.

Thanks for your patience and persistence tracking this one down.

Thanks for working through this one with me  You're right.. as soon as I create a blog post, the permissions appear in the API call. Great.. I can work with this now. Thanks again!