I think I've seen what you are talking about. No matter how you set the Authorizations in the Role, or in the OPT, when I create an object, my role gets Object.*.
I believe I submitted a defect for this, thought I can't find the number. It may have been addressed in 7.6 or in 8.0. I think, though, if your Role has only Object.Read, even if the object is created w/ Object.* for your role, you will only be able to read it. That's what I found when I ran into this, is it the same for you, or do you actually have Object.* on the object even though your Role has only Object.Read ?
I think the issue is slightly different to the scenario you gave. What we have for example, is a user who we have given permission to for example create a Depot Group. His Authorisations allow him to DepotGroup.Create, Write, Read, Modify and so on, but not CreateACL or ModifyACL. The idea being that this user can create a new Depot Group which receives a set of permissions that allow only people in the same role to access. By him not being allowed access to modify the ACL, we can thereby prevent him to giving access to that Depot Group for roles who should not have access. However, because of the DepotGroup.* permissions that seem to be applied by default, we cannot enforce this.
Does that make sense? Its a tricky one to explain
I think I know what you are talking about... have you verified that you can actually change acls on the object in question w/ your role that shouldn't be able to, to be sure that it's not a GUI display issue vs an actual ACL issue? if it's an acl issue i'd open a defect ticket for sure.
i thought i saw this back in 7.4.x and it was fixed in 7.5/6 or a 7.4 hotfix, but I could be wrong.
Thanks for your replies. I think you're right. Not sure if it's a GUI display issue, but of course, in my scenario, the user's role which is associated with an ACL template that allows for example all DepotFolder system authorizations except CreateACL & ModifyACL. The role's system authorizations also do not allow the user to create of modify ACLs. So even though this user can create a DepotFolder, and the permissions applied to it for the creator by default are <object_type>.*, therefore overriding the permissions associated with the role's ACL template, when that user then goes back to attempt to modify the ACLs of that object, the role's system authorizations prevent it anyway.
Logical really when you think about it. I think it was just the fact that it was showing up with all permissions for which ever user created the object was throwing me.
Many thanks for your help!
Regards - Lee