Dear community,
in our Insight, we do have several object types, which stand in a hierarchy to each other.
I did set some developer rights for a group on object type A.
Will this group be able the act as a developer on object type A.1 and A.2 as well? Or do I need to actively set the developer rights on that level as well?
The Atlassian documentation seems to suggest that rights are inherited from the object schema. (Configuring roles and permissions | Jira Service Management Data Center and Server 4.17 | Atlassian Documentation) Is this also true for the sub-object types A.1 and A.2 in my example? Was this behaviour recently changed?
It would be very painfull, as I would have to go through a lot of sub-object types to set the rights.
thanks for any insights.
EDIT: Insight version 9.1.7
Hi Chris.
Your observation is correct - Object Type Roles have priority over Parent Object Type Roles, which in turn have priority over Object Schema Roles.
Not specifying a User / Group in an Object Type Role - the Object Type will inherit its permissions from the Schema / Parent.
If you do specify a Role in a Child Object Type - it will, indeed, ignore Parent / Schema Role configurations for that particular Role.
Please have a look here for reference - see the "Good to know" note.
There is an exceptions to this behavior:
The Insight Admin Role and a Schema Manager Roles cannot be overridden by an Object Type Role.
If a User is set as an Object Type Manager, any Schema Manager will be also able to Manage the Object Type.
If you wish for a Schema Developer (or a Parent Object Type Developer) to have the same role on a Child Object type; either do not set any User / Group to the Child's Developer Role, or, if you want to add users to be developers of the Child, you must indicate ALL the Users having this Role on that Object Type, even if they are already set on the Parent Object Type as Devs.
This allows enforcing Roles with a certain hierarchy, where the rule is to Override users/devs from previous levels, unless knowingly added - instead of unknowingly inheriting Roles from previous levels.
This also allows to hide Object Types from Users, for example, in an HR Schema:
User A has User Role on an object Type: Employee. The HR Team are set as Developers.
Employee is referencing a Child Object Type called "Salary Base" where the HR Team are set as a group for the Object Type Users, while HR Managers are the Object Type's Managers and the Accounting Team are set as Developers.
While User A can view User Objects, the Salary Base Attribute (a reference to the "Salary Base" object) - is not even visible to User A, since the User has no role in the referenced Object Type. Some Attributes may be configured as Hidden as well - so a User Role cannot view these.
User B is an HR employee, and can create new User Objects, as well as assign it its corresponding "Salary Base" - but cannot modify the Salary base itself...
This is just one simple example.
Please let us know if you require any additional information.
Kind regards,
Yinon
Atlassian Support
I just found out, what is happening:
Roles and permissions of object type A.1 is empty, the roles and permissions of object type A are used.
Roles and permissions of object type A.2: a week ago, I added two users. ohter then that, the roles an permissions page was empty. -> this caused insight to only give those two new users access according to my settings, but no rights for other users where inherited anymore.
Is this a bug? In my case, I would like INSIGHT to use the roles and permissions "additive" and not "exclusively one or the other".
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hi Jorden,
could you please check, if your system behaves the same as ours? If yes, I would open a bug report with atlassian.
many thanks,
Chris
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Yep seems to overwrite it.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
It should indeed inherit. For us it still works this way, so I think you're good to go.
Kind regards
Jorden
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Online forums and learning are now in one easy-to-use experience.
By continuing, you accept the updated Community Terms of Use and acknowledge the Privacy Policy. Your public name, photo, and achievements may be publicly visible and available in search engines.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.