+1
On 7/12/18, 1:58 PM, "Rawlin Peters" wrote:
+1 on setting null tenants to "root" when tenancy is disabled and
"unassigned" when tenancy is enabled.
If we set null tenants to "unassigned" when tenancy is disabled and
enable tenancy after the migration, those tenants now o
+1 on setting null tenants to "root" when tenancy is disabled and
"unassigned" when tenancy is enabled.
If we set null tenants to "unassigned" when tenancy is disabled and
enable tenancy after the migration, those tenants now only see
"unassigned" stuff rather than *everything* like they saw befor
The advantage is not needing to check against the list of viable tenants
plus null. Gets rid of edge cases where a tenant of NULL either must be
included or excluded from a list. With an actual tenant id, it's
explicit.
The other advantage is that I'm aware of cases where the tenant_id is
cur
What is the advantage of having an "unassigned" value that means
effectively what null currently means? In the tenancy situation, we've
already got a value that means unassigned: null. And in a non-tenancy
situation, there's no reason to assign anything other than null to the
value, since it's of n
Ok, just so i'm clear. On clean install or upgrade, in seeds.sql (or
wherever) create a new tenant called "Unassigned" with parent=root.
If use_tenancy = 0 (off):
find all users where tenant = null and set tenant = root
find all dss where tenant = null and set tenant = root
find all origins where
Along those lines, there are currently no constraints in the db to
enforce that everything has an assigned tenant. I'd like to change that.
Currently, it's possible to have tenancy turned on but still have NULL
tenant_id on a user, deliveryservice, or origin. That leads to ambiguous
situat
+1 I think giving reasonable defaults and making the role/capabilities
feature available makes for it's awareness as well.
-Dew
On Sat, Jun 16, 2018 at 9:18 PM Dave Neuman wrote:
> I'll admit I am not super close to this problem so I don't understand it
> well but, from what I have read, I ten
although it may appear that roles/capabilities is more complex than the
current system (roles/priv_level), i actually think it's a lot easier from
a user perspective. let me explain.
can you tell me the difference between the operations role (priv level=20)
and the portal role (priv level=15). me
>when roles/capabilities are introduced our roles will look like this:
>
>admin (all capabilities)
>operations (the capabilities required to at a minimum to reproduce current
>access level of priv level=20. capabilities yet to be determined)
That's essentially what I was asking. As long as we can
I also agree with requiring tenancy and roles/capabilities in 3.0. In
fact, Traffic Portal already requires a tenant to be selected today,
regardless of whether or not use_tenancy is true.
We should try to balance usability with ease of development, and we
could easily provide a DB migration that
I'll admit I am not super close to this problem so I don't understand it
well but, from what I have read, I tend to agree with Jeremy. If we are
going to have roles/capabilities we need to just incorporate them into the
system and be done with it. We should have able to provide reasonable
default
regarding tenancy:
@Nir is right. If you don't feel like using tenancy, then you give all your
users tenant=root. so tenancy is easy to sidestep if you're not interested
in using it.
regarding roles:
here are our current roles:
admin (priv level=30)
operations (20)
portal (15) <-- terrible name
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 be
>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
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
turn
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 pa
16 matches
Mail list logo
