starred/netbox
1
0
Fork 0
mirror of https://github.com/netbox-community/netbox.git synced 2026-01-11 21:10:29 +01:00
Code Issues 273 Packages Projects Releases 10 Wiki Activity

Inconsistent "Group" value shown on table view vs detailed view #5771

New Issue
Closed
opened 2025-12-29 19:32:30 +01:00 by adam · 5 comments
adam commented 2025-12-29 19:32:30 +01:00
Owner
Copy Link

Originally created by @damiankaczkowski on GitHub (Dec 14, 2021).

NetBox version

v3.1.1

Python version

3.9

Steps to Reproduce

  1. Create a tenant. Do not fill a "Group" for a new tenant.
  2. Go to created tenant details view -> "/tenancy/tenants/1/"
  3. Spot that "Group' shows "None" value.
  4. Go to tenants table view -> "/tenancy/tenants/"
  5. Spot that "Group" now shows "—" value for the same tenant.

Expected Behavior

Data shown is consistent between different menus/views.

Observed Behavior

Data shown is inconsistent between different menus/views.

Originally created by @damiankaczkowski on GitHub (Dec 14, 2021). ### NetBox version v3.1.1 ### Python version 3.9 ### Steps to Reproduce 1. Create a tenant. Do not fill a "Group" for a new tenant. 2. Go to created tenant details view -> "/tenancy/tenants/1/" 3. Spot that "Group' shows "None" value. 4. Go to tenants table view -> "/tenancy/tenants/" 5. Spot that "Group" now shows "—" value for the same tenant. ### Expected Behavior Data shown is consistent between different menus/views. ### Observed Behavior Data shown is inconsistent between different menus/views.
adam closed this issue 2025-12-29 19:32:30 +01:00
adam commented 2025-12-29 19:32:31 +01:00
Author
Owner
Copy Link

@DanSheps commented on GitHub (Dec 14, 2021):

Damian,

You will see that all throughout NetBox this duality between placeholder vs "None" exists depending on if you are looking at the List view or the Detail view. This is because a list view can only contain so much information we need to try and make it presentable and easy to digest.

A row with some data and a bunch of placeholders is much easier to read then a row of data with "None" interspersed between.

I am going to close this issue as it is "not a bug". Please be sure you review our contributing guidelines before opening an issue in the future.

@DanSheps commented on GitHub (Dec 14, 2021): Damian, You will see that all throughout NetBox this duality between placeholder vs "None" exists depending on if you are looking at the List view or the Detail view. This is because a list view can only contain so much information we need to try and make it presentable and easy to digest. A row with some data and a bunch of placeholders is much easier to read then a row of data with "None" interspersed between. I am going to close this issue as it is "not a bug". Please be sure you review our [contributing guidelines](https://github.com/netbox-community/netbox/blob/develop/CONTRIBUTING.md) before opening an issue in the future.
adam commented 2025-12-29 19:32:31 +01:00
Author
Owner
Copy Link

@damiankaczkowski commented on GitHub (Dec 15, 2021):

Daniel,

Here is why it is a bug and ticket should stay open or at least be discussed before getting closed.

  • An argument with data presentation is very weak because it doesn't matter when you create and select groups for tenants. Suddenly both views shows the same "real" (database) data irrespective of subjective "data presentation" feelings.
  • If you create a group and name it "None" then you will have a name clash which would lead to a bunch of new potential problems, probably breaking netbox system here and there and dependent systems too.
  • Few times I found similar errors and they were fixed eg. #8033, #8038. From the user perspective I should not need to know what are the system internals. Systems should just work and behave consistent. If I spot the same inconsistency before, then why one inconsistency was bad and was fixed and the other is NOT bad and should stay? How should I know which one is ok? If you would say: "This is broken by design" then it would be clear to me.
  • As stated here #8062 - this is probably related and breaks import/export and probably other operations too. Again I understand "by design" argument. But from user perspective it is just confusing. One build-in export gives you "that" data but the other user export gives you very different data (and that user export is the simplest one which should just give you data stored in database just like build-in "All Data" export does. More, it gives you that data... but unfortunately only for some fields... for the other fields it give you random hardcoded data, which again is inconsistent and confusing behavior for a simple user). See example below.
  • When you come to the point that you will translate this software to other languages showing hardcoded "None" to non-english users just does not work. Now, is translating hardcoded "None" to every language more reasonable than just showing real data instead...? Clearly "-" in this case is better choice and tells everything it needs to tell to every user, even to non english speaking ones.
  • Data is even more inconsistent between GUI and API - and here I understand - showing "null" in GUI is not user friendly at all.

Might find and list a few more arguments but I am just short of time. Please keep in mind that I am spending my time to give you well described reports, each with easy to reproduce "receipt" and just closing tickets in no time with literally no discussion based on subjective feelings is a good way to demotivate any individual to invest more time and work that this project could otherwise benefit of.

Finishing with the mentioned example of a breakage to which hardcoding non real data leads:

  • "Real" data in database:
    tenant1 - group "None" selected
    tenant2 - group "Test" selected
    tenant3 - no group selected

  • Data exported via "All Data":
    ID,Name,Slug,Group,Description,Comments
    1,tenant1,tenant1,None,,
    2,tenant2,tenant2,Test,,
    3,tenant3,tenant3,,,

  • Data exported via simplest template: {{ tenant.id }},{{ tenant.name }},{{ tenant.slug }},{{ tenant.group }},{{ tenant.description }},{{ tenant.comments }}:
    id,name,slug,group,description,comments
    1,tenant1,tenant1,None,,
    2,tenant2,tenant2,Test,,
    3,tenant3,tenant3,None,, <- !!!???

Is this really a well-designed-system proper behavior? I see here two very different selections/input that gives you the same output value without any way to differentiate between them. Even if "{{ tenant.group }}" "gave me what I asked for" as @jeremystretch said, this is clearly "ok" only for developer who knows system internals, but not for the simple user who gets two very same outputs from the two very different inputs and wonders what is going on.

@damiankaczkowski commented on GitHub (Dec 15, 2021): Daniel, Here is why it is a bug and ticket should stay open or at least be discussed before getting closed. - An argument with data presentation is very weak because it doesn't matter when you create and select groups for tenants. Suddenly both views shows the same "real" (database) data irrespective of subjective "data presentation" feelings. - If you create a group and name it "None" then you will have a name clash which would lead to a bunch of new potential problems, probably breaking netbox system here and there and dependent systems too. - Few times I found similar errors and they were fixed eg. #8033, #8038. From the user perspective I should not need to know what are the system internals. Systems should just work and behave consistent. If I spot the same inconsistency before, then why one inconsistency was bad and was fixed and the other is NOT bad and should stay? How should I know which one is ok? If you would say: "This is broken by design" then it would be clear to me. - As stated here #8062 - this is probably related and breaks import/export and probably other operations too. Again I understand "by design" argument. But from user perspective it is just confusing. One build-in export gives you "that" data but the other user export gives you very different data (and that user export is the simplest one which should just give you data stored in database just like build-in "All Data" export does. More, it gives you that data... but unfortunately only for some fields... for the other fields it give you random hardcoded data, which again is inconsistent and confusing behavior for a simple user). See example below. - When you come to the point that you will translate this software to other languages showing hardcoded "None" to non-english users just does not work. Now, is translating hardcoded "None" to every language more reasonable than just showing real data instead...? Clearly "-" in this case is better choice and tells everything it needs to tell to every user, even to non english speaking ones. - Data is even more inconsistent between GUI and API - and here I understand - showing "null" in GUI is not user friendly at all. **Might find and list a few more arguments but I am just short of time. Please keep in mind that I am spending my time to give you well described reports, each with easy to reproduce "receipt" and just closing tickets in no time with literally no discussion based on subjective feelings is a good way to demotivate any individual to invest more time and work that this project could otherwise benefit of.** Finishing with the mentioned example of a breakage to which hardcoding non real data leads: - "Real" data in database: tenant1 - group "None" selected tenant2 - group "Test" selected tenant3 - no group selected - Data exported via "All Data": ID,Name,Slug,Group,Description,Comments 1,tenant1,tenant1,None,, 2,tenant2,tenant2,Test,, 3,tenant3,tenant3,,, - Data exported via simplest template: {{ tenant.id }},{{ tenant.name }},{{ tenant.slug }},{{ tenant.group }},{{ tenant.description }},{{ tenant.comments }}: id,name,slug,group,description,comments 1,tenant1,tenant1,None,, 2,tenant2,tenant2,Test,, 3,tenant3,tenant3,None,, **<- !!!???** Is this really a well-designed-system proper behavior? I see here two very different selections/input that gives you the same output value without any way to differentiate between them. Even if "{{ tenant.group }}" "gave me what I asked for" as @jeremystretch said, this is clearly "ok" only for developer who knows system internals, but not for the simple user who gets two very same outputs from the two very different inputs and wonders what is going on.
adam commented 2025-12-29 19:32:32 +01:00
Author
Owner
Copy Link

@kkthxbye-code commented on GitHub (Dec 15, 2021):

It would help your case to not include export templates in your reasoning. It's an advanced feature, and you are getting exactly what you are asking for (the value is None, you are casting it to a string, which is "None"). If you don't want to cast None to the string "None" use {{ tenant.group|default('', true) }}.

I have no opinion on the how None values are displayed in the UI, but be aware that "—" is a valid name for a tenant, so changing the detail view to show — instead of None will still not solve the inconsistancy, unless I'm misunderstanding your issue.

@kkthxbye-code commented on GitHub (Dec 15, 2021): It would help your case to not include export templates in your reasoning. It's an advanced feature, and you are getting exactly what you are asking for (the value is None, you are casting it to a string, which is "None"). If you don't want to cast None to the string "None" use `{{ tenant.group|default('', true) }}`. I have no opinion on the how None values are displayed in the UI, but be aware that "—" is a valid name for a tenant, so changing the detail view to show — instead of None will still not solve the inconsistancy, unless I'm misunderstanding your issue.
adam commented 2025-12-29 19:32:32 +01:00
Author
Owner
Copy Link

@damiankaczkowski commented on GitHub (Dec 15, 2021):

Thank you @kkthxbye-code . I just did like @jeremystretch told me to do and do asked for help here #8065 but haven't got any help regarding this what you wrote till now. Will paste your hint there. And your point is valid, incuding export template example in here does not help in my reasoning when I now know the "cast" thingy. I have read the jinja docs and haven't found by myself that the use of default() would work in this case. Thank you again.

The rest points are imo more less valid to my best knowledge. I leave up to developers discretion to decide if its worth changes or no. Now I see it probably won't break anything, so maybe it is minor.

Anyway few words of explanation would help in the first place or maybe a simple example in the docs cause I think - maybe it is an advanced feature, but I suppose very popular one. I haven't seen docs saying I have to deals with some "cast" thingy when getting values out of system. Maybe that is worth noting this in the docs or just putting some real life examples so others will know with what they deal with.

@damiankaczkowski commented on GitHub (Dec 15, 2021): Thank you @kkthxbye-code . I just did like @jeremystretch told me to do and do asked for help here #8065 but haven't got any help regarding this what you wrote till now. Will paste your hint there. And your point is valid, incuding export template example in here does not help in my reasoning when I now know the "cast" thingy. I have read the jinja docs and haven't found by myself that the use of default() would work in this case. Thank you again. The rest points are imo more less valid to my best knowledge. I leave up to developers discretion to decide if its worth changes or no. Now I see it probably won't break anything, so maybe it is minor. Anyway few words of explanation would help in the first place or maybe a simple example in the docs cause I think - maybe it is an advanced feature, but I suppose very popular one. I haven't seen docs saying I have to deals with some "cast" thingy when getting values out of system. Maybe that is worth noting this in the docs or just putting some real life examples so others will know with what they deal with.
adam commented 2025-12-29 19:32:32 +01:00
Author
Owner
Copy Link

@DanSheps commented on GitHub (Dec 15, 2021):

  • A display issue with a integer is very different then this display issue. In both of those cases, the value should never be "None". Both of those are instances where zero should be present, but weren't. It isn't a case where the value was legitimately nulled.
  • If you create a group with the mdash ("—") it is going to be in conflict too. This is a none argument.
  • If we translate it into different languages, we will cross that bridge when we get there, there are other places this would need to be addressed as well. This would be a lot of work however so it is unlikely to happen in the near future.

We do appreciate your time for filing bugs.

However, this display is consistent with the rest of the views within NetBox and won't be changed as a bug. If you would like everything that is a null value to show as a mdash, it would need to be a FR and it would need to be all views not just a single cherry picked view.

@DanSheps commented on GitHub (Dec 15, 2021): * A display issue with a integer is very different then this display issue. In both of those cases, the value should never be "None". Both of those are instances where zero should be present, but weren't. It isn't a case where the value was legitimately nulled. * If you create a group with the mdash ("—") it is going to be in conflict too. This is a none argument. * If we translate it into different languages, we will cross that bridge when we get there, there are other places this would need to be addressed as well. This would be a lot of work however so it is unlikely to happen in the near future. We do appreciate your time for filing bugs. However, this display is *consistent* with the rest of the views within NetBox and won't be changed as a bug. If you would like everything that is a null value to show as a mdash, it would need to be a FR and it would need to be **all** views not just a single cherry picked view.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
beta
breaking change
complexity: high
complexity: low
complexity: medium
needs milestone
netbox
pending closure
plugin candidate
pull-request
Mirrored from GitHub Pull Request
 severity: high
severity: low
severity: medium
status: accepted
status: backlog
status: blocked
status: duplicate
status: needs owner
status: needs triage
status: revisions needed
status: under review
topic: GraphQL
topic: Internationalization
topic: OpenAPI
topic: UI/UX
topic: cabling
topic: event rules
topic: htmx navigation
topic: industrialization
topic: migrations
topic: plugins
topic: scripts
topic: templating
topic: testing
type: bug
type: deprecation
type: documentation
type: feature
type: housekeeping
type: translation
No Label
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
adam
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/netbox#5771
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?