Hi, I'm with Jeremy on that. The "use_tenancy" flag came to allow simple transition to the tenanted world: On the transition, the TC owner should adjust all tenancies, most importantly create a "root tenant" admin, and only then put the use_tenancy flag on.
For 3.0 I believe that tenancy should become mandatory - transition period done. A TC that does not need tenants, should just put all elements under the root tenant. No need to maintain two pathes in the code.... We can do the same for "role/capability" - adding a global knob just for the transition. Nir On Thu, Jun 14, 2018 at 9:38 PM, Robert Butts <[email protected]> wrote: > >will the self-service stuff rob butts is working on be affected in any > way? Will self-service truly be turned off via a parameter? > > What I'm working on, change integrity, shouldn't be affected by turning off > tenancy/roles/capabilities. > > And we shouldn't turn off the API-visible parts of what I'll be doing: DS > snapshots, server snapshots, etc. > > We should be able to turn off the complex permissions system for > self-service, while still retaining safe change integrity via the timestamp > system. > > >it would be nice if TC 3.0 made tenancy / roles & capabilities a > requirement > > Requiring tenancy/roles/capabilities would certainly make the code nicer, > but I'm afraid it'll make the software much more difficult to use, for > users who want an internal CDN, and have no need for a complex permissions > framework. > > @mitchell852 Is it possible to add GUI shims in Traffic Portal, and/or API > helpers, to make the interface pretend like tenancy/roles/capabilities > don't exist? E.g. to grant all permissions and the root tenant to all users > on user-creation, if the "use_self_service" config flag is set? So all the > code can keep working the same way, but people who don't need > tenancy/roles/capabilities can still have the existing simpler interface? > How difficult would that be? > > > On Thu, Jun 14, 2018 at 12:18 PM, Jeremy Mitchell <[email protected]> > wrote: > > > I like the idea but what will it really mean to turn off > use_self_service. > > I know it will mean tenancy will be disabled and API permissions won't be > > checked against a user's capabilities, but will the self-service stuff > rob > > butts is working on be affected in any way? Will self-service truly be > > turned off via a parameter? > > > > IMO it would be nice if TC 3.0 made tenancy / roles & capabilities a > > requirement. No more turning it on and off. The scope of what you see is > > dictated by your tenancy and the api's that you have access to are > dictated > > by your capabilities. > > > > Jeremy > > > > On Thu, Jun 14, 2018 at 11:49 AM, Volz, Dylan <[email protected]> > > wrote: > > > > > Hi Traffic Controllers, > > > > > > I am working on enforcing the roles->capabilities system as a > replacement > > > for the soon-to-be legacy priv level system. Like tenancy this is a > > feature > > > moving us towards self-service; so to minimize our code/behavior paths > > > I would like to propose renaming the use_tenancy parameter to > > > use_self_service, so that if it is turned on both tenancy and > > capabilities > > > are applied. This prevents some hairy cases arising when capabilities > are > > > on and tenancy is off or vice versa. Let me know if you have any > > questions, > > > concerns, or suggestions. > > > > > > Thanks, > > > Dylan > > > > > >
