Context Template with Permission on Roles

[LG_10096154]

Hello experts.

We have a few old templates created by folks who have long left the company.

It looks like they call out roles that we have in or RoleRB file and a few we do not.

I think they also call out the Permissions on Roles for those none RoleRB roles?

Any guidance would be helpful

[avillanueva]

Help me understand. Are these currently loaded in the system or are these offline? I cannot remember if the system will reject them if the roles do not exist but either way, it would cause a problem. Are you looking to import them but are stuck by the missing roles? Two choices:

1. Add the missing roles to the system. You can then import, create an area using that template, modify it to remove those roles which should remove ACLs, then re-export/save a new template.

2. Edit the XML file manually to remove the roles and any ACLs. Should not be too hard to do.

[jlecoz]

Hi, 

The role I see in your screenshot is teamMembers.

This is a pseudo role that is not in the resource bundle or defined at org level.

It always exists and is populated with the context team members excluding the one with the Guest role.

[avillanueva]

Good catch, I did not see that.

[LG_10096154]

Yes, Team Members is a pseudo role (much like Guest). If the Role is not in the Role RB file, the template will just create it as a local role and it will fall under the ACL for Team members.

My question is about what looks to me like permissions on roles call out in the template? I don't ready XML so I'm just guessing but it looks like that is what it is doing by hiding the actions.

Can someone confirm and point me to how to use this feature?

Thanks. 

[jlecoz]

What you have displayed are AdHoc access control rules.

You set such a rule for a folder or an object. For the object, it is not assigned for a given state this is a general access rule set for all object states.

These ad-hoc rules are going in addition to regular ACL (defined with an object, a role, a state, and a set of permissions). You can grant access using these rules but you can't remove access against regular rules.

If you implement such a rule you need to have set very restrictive regular rules as you can only grant permissions with it.

This is not like hiding a command with profiles.

The out of the box product  and library templates are not containing such ad-hoc rule, what you see has been configured.

UI setting to set such permissions:

You can set them in the UI here: 

[LG_10096154]

Thanks. Any idea where I can find details on this? We have many context templates for each type (Project, Product and Library) and most have these Access Controls in them.

It sounds like they can only be used to grant access. For example, the Role normally only had read and download but the template then ad hoc provides create?

[jlecoz]

You can check on the tech support web site about Ad Hoc Access Control. 

You are right you can grant only. You may have access control rules set to READ DOWNLOAD and grant the MODIFY with these AdHoc rules.

AdHoc rules are commonly used in Project contexts.

[LG_10096154]

Thanks. I'm not keen on putting the access within templates as they are hard to find. Rather look at the ACL permissions and know what's going on.

But having a Role called Read Only and ACL permissions that look like read only but then in the context the role can create is annoying.

[jlecoz]

I agree, I always avoided having access rules calculated from a combination of different access control methods.

It is better to use only one feature to set the access control this facilitates access control maintenance and understanding.

But sometimes we have to cope with business requirements.