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

How do I have SYSTEM WIDE change the permission schema for Owners, Manager and Member?

I know there is an override to the default possible but it is a tedious operation having to do this for every permission setting

The use case is: I have a community where owners permissions need to be reduced to manager role.

Though your reaction is: Why do you not assign manager role to them? The system also has other hard wires to the owner role that are needed for this owner- role.

I just need to take away on system level owner permissions instead of having to deselect it every time I create one of hundreds of groups.

Parents
  • 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  

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

  • In v11 there is no option to modify a template, the best solution would be a plugin or automation that sets permissions individually on create, update or whatever is appropriate for your scenario

  •  We're on v11 & I'm looking at exactly this. I've been trying to get my head around what I can get to via the script API.

    From what I can see, I can't change the defaults at the Group level via an automation script, i.e. these don't seem to be accessible via the script API; Manage Group > Permissions > Member > [big long list of application defaults]. My initial brief was to change those defaults when the Group was created, but after looking at this for a few hours I don't think that's possible, right?

    Instead I'd write an automation for when the Application is created within a Group, and set the permissions on the app according to our set of desired defaults? (using $core_v3_permission.Set).

  • 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.

Reply
  • 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.

Children