You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
You said that the changes to the user model would break the model for existing netbox users.
I would like to understand that, because I didn't think it would break it, that would obviously just be bad.
My focus in this FR was to add a new field "default_tenant", which can be empty. Just as an option for netbox users to define that a specific tenant gets autopopulated.
One idea I had as workaround would be to make a custom script to set that tenant field for all objects the user creates, but that would be annoying: If I have automation that gets triggered by the "created" event, it would always have to wait for the change from the custom script, therefore I couldnt use the "created" event at all (for example in Ansible EDA).
It would be nice to have this in Netbox, directly before any database changes happen or any events get triggered.
But going back.. Maybe I am misunderstanding what you mean by breaking? For me that would mean all netbox users would have to make changes to all their users they created in netbox, before switching to that new version.
But if it's just as new field, that doesn't have to be populated with any data, it shouldn't break it?
Same with the "tenants" field I addressed. I would just see it as an option, it's not a mandatory field. Just an easy wrapper to create permissions. But really this wasn't the main point here and I can totally understand this is not planned, it's more about the default assignment of a tenant to resources.
Furthermore, thanks for your clarification on the resource tenancy vs user tenancy.
I would like to provide a bit more information.
We have branches in many different countries, that all have local IT teams that manage the services in their country,
We, as global NOC would like to provide access to the countries so they can see and manage their own infrastructure, without setting up like... 40 different instances of Netbox.
I can see though how that idea of data isolation would be less of an issue for service providers that manage their infra in netbox, but in our case it just feels.. janky, you know?
It's not about full user tenancy in my opinion. It's still about resource tenancy, just guardrails assigned to a user to ensure resource tenancy, would you disagree?
I also saw the other comment about Custom Validators, I haven't tried that yet and I will check it out to see if that fits the need.
ok that was a lot of yapping, I hope I was able to give u some more context xD
tl;dr
Why do the changes break the user model?
I'm still very new and maybe I am missing something here that would break the model, would love to learn.
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
Uh oh!
There was an error while loading. Please reload this page.
-
Hey @jnovinger
Thanks for looking at my FR #20126 !
You said that the changes to the user model would break the model for existing netbox users.
I would like to understand that, because I didn't think it would break it, that would obviously just be bad.
My focus in this FR was to add a new field "default_tenant", which can be empty. Just as an option for netbox users to define that a specific tenant gets autopopulated.
One idea I had as workaround would be to make a custom script to set that tenant field for all objects the user creates, but that would be annoying: If I have automation that gets triggered by the "created" event, it would always have to wait for the change from the custom script, therefore I couldnt use the "created" event at all (for example in Ansible EDA).
It would be nice to have this in Netbox, directly before any database changes happen or any events get triggered.
But going back.. Maybe I am misunderstanding what you mean by breaking? For me that would mean all netbox users would have to make changes to all their users they created in netbox, before switching to that new version.
But if it's just as new field, that doesn't have to be populated with any data, it shouldn't break it?
Same with the "tenants" field I addressed. I would just see it as an option, it's not a mandatory field. Just an easy wrapper to create permissions. But really this wasn't the main point here and I can totally understand this is not planned, it's more about the default assignment of a tenant to resources.
Furthermore, thanks for your clarification on the resource tenancy vs user tenancy.
I would like to provide a bit more information.
We have branches in many different countries, that all have local IT teams that manage the services in their country,
We, as global NOC would like to provide access to the countries so they can see and manage their own infrastructure, without setting up like... 40 different instances of Netbox.
I can see though how that idea of data isolation would be less of an issue for service providers that manage their infra in netbox, but in our case it just feels.. janky, you know?
It's not about full user tenancy in my opinion. It's still about resource tenancy, just guardrails assigned to a user to ensure resource tenancy, would you disagree?
I also saw the other comment about Custom Validators, I haven't tried that yet and I will check it out to see if that fits the need.
ok that was a lot of yapping, I hope I was able to give u some more context xD
tl;dr
Why do the changes break the user model?
I'm still very new and maybe I am missing something here that would break the model, would love to learn.
Beta Was this translation helpful? Give feedback.
All reactions