Assign Object Role Responsibilities on a Repository Object to a User or Group

Please refer to the responsibilities and capabilities assignment model for an explanation of how users relate to role assignment.

If NO user or group is assigned the Viewer security role on an object (or any of its parents), then all users will be able to view the object.

However, If ANY user or group is assigned the Viewer security role on an object (or any of its parents), then all other users will NOT be able to view the object (those users not assigned the Viewer security role on an object or a member of such a group).???

The responsibilities that you assign for a configuration apply to the configuration, not its models. Thus, when you assign a group or user the Edit Metadata capability for that configuration then they have the ability to, for example, add a model to the configuration, but do not necessarily have permissions to edit the contained models within the configuration. Instead, each model in the configuration may also have its own responsibility assignments. Thus, if you wish to be able to edit the contained model properties, you will need to assign the Edit Metadata responsibility to that user or group on those objects, not just the configuration they are contained within. This is a very powerful feature that allows one to control who is Editor or Manager for individual models in a configuration, separately from security role assignments to the configuration itself.

You may, of course, use repository folder structure to manage the object responsibility assignments. For example, you may place all the models which should be editable in the same folder and assign the Edit Metadata responsibility at that level for the group or users you wish to be able to edit all of those models. This is because, while object responsibility assignments are not inherited through the configuration, security role assignments are inherited through the actual folder structure in Talend Data Catalog .

For viewing rights to a model (or glossary, etc.), the simplest best practice is to control viewing via configuration access, and not through restricting viewer rights to specific objects which may be in a configuration. This suggestion follows from the fact that any user who needs to open a configuration MUST ALSO have view permissions to all of the models in the configuration (either by explicitly assigning the View Metadata object responsibility to all the objects contained, or if no such assignment has been made, then the object is by default viewable). So, the easiest way to manage access to a model is to simply not include it in any open configuration.

Again, if ANY model of a configuration is not viewable by a user then the entire configuration is not viewable by that user.