Github user nir-sopher commented on a diff in the pull request:

    
https://github.com/apache/incubator-trafficcontrol/pull/433#discussion_r110647853
  
    --- Diff: traffic_ops/app/lib/API/Tenant.pm ---
    @@ -162,11 +179,17 @@ sub create {
                return $self->alert("Tenant name is required.");
        }
     
    +   #not allowing to create additional root tenants.
    +   #there is no real problem with that, but no real use also
        my $parent_id = $params->{parentId};
        if ( !defined($parent_id) ) {
                return $self->alert("Parent Id is required.");
        }
     
    +   if (!verify_tenancy_for_write($self, $params->{parentId})) {
    --- End diff --
    
    The read/write separation came to ease the move to more complicated 
relationships between tenants in the future.
    What I really aimed to is a read/write function per tenant anchor:
    verify_tenancy_for_tenant_read/verify_tenancy_for_tenant_write
    verify_tenancy_for_user_read/verify_tenancy_for_user_write
    verify_tenancy_for_ds_read/verify_tenancy_for_ds_write
    verify_tenancy_for_cdn_read/verify_tenancy_for_cdn_write
    
    and maybe more (e.g. 
verify_tenancy_for_profile_read/verify_tenancy_for_profile_write).
    
    The need of such an interface is the support of more complicated tenants 
relationships. Most cases are indeed indirectly covered by the AAA but not all.
    For example, the ISP admin has the ability to manage parameters within a 
profile. The CP admin also has this capability, as a profile can be now set to 
a DS. 
    If now I want to allow the users of ISP1 tenant to view profiles of CP1 
tenant, but not to edit them, I need to distinguish read and write on the 
tenancy level.
    
    The functional API I'm adding now is far from being complete. Much more 
should be considered when deciding on the final one.  For now I only separate 
read&write to simplify further changes. 
    Additionally, this separation has an added value, allowing LDAP users to 
view all data but not write to it.



---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at [email protected] or file a JIRA ticket
with INFRA.
---

Reply via email to