Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Device-Type 'slug' not visible in main view #2560

Closed
bdlamprecht opened this issue Nov 7, 2018 · 7 comments
Closed

Device-Type 'slug' not visible in main view #2560

bdlamprecht opened this issue Nov 7, 2018 · 7 comments
Labels
status: accepted This issue has been accepted for implementation type: feature Introduction of new functionality to the application

Comments

@bdlamprecht
Copy link
Contributor

Environment

  • Python version: 3.6
  • NetBox version: v2.4.6

Steps to Reproduce

When viewing an individual device-type at http://netbox.local/dcim/device-types/PK/`, the slug property is not visible:

image

Similarily, I know the list of device-types is full of other properties that are more important to see than slug:

image

The only place you can see what the slug is set to is by editing the object:

image

Expected Behavior

I'm not sure if this was ever visible before, but I think when viewing a single object, all of the properties tied to it should be seen.

Observed Behavior

The device-type property is only visible when editing an object

@jeremystretch
Copy link
Member

This is the case with all objects which have a slug. The slug's only purpose is to help form a "clean" but human-friendly URL (e.g. ?company=foo-corp-inc instead of ?company=Foo%20Corp%2C%20Inc.) and in most cases the automatically generated slug suffices. Can you elaborate on why you'd like to include it?

@jeremystretch jeremystretch added the status: under review Further discussion is needed to determine this issue's scope and/or implementation label Nov 7, 2018
@bdlamprecht
Copy link
Contributor Author

Yes, I know what slugs are used for. I think it is a great feature.

As an explanation for this bug or FR, I tend to change the default auto-generated slug.
With that being said, I recently ran into an issue where I had mistakenly created a device_type with one slug and tried to update my development box using ninech/netbox:v2.4.7's docker image, and it failed.
I spent about 30 minutes trying to see why that happened and finally narrowed it down to a duplicate slug in one of the data seed or initializer's that I'm using.

In short, in my opinion, having all of the properties visible when viewing an individual primary object would be beneficial and don't see any negative aspects about it.

I'll leave it up to you to decide, but those are just my thoughts.

@mmahacek
Copy link
Contributor

mmahacek commented Nov 8, 2018

Given that other object types will display the slug either in the table view (such as DeviceRole, Platform, and Manufacturer) or in the URL (sites/tenants), I don't think it would be unreasonable to put the slug on the Device Type page. A quick glace through the DCIM features, DeviceType seems to be the only one without easy access to view slugs.

We are using customized DeviceRole slugs to match category names in our monitoring system while keeping the display name in Netbox "pretty".

@jeremystretch
Copy link
Member

This raises the question: Should DeviceType even have a slug? I'm not sure we actually use it for anything in the UI, but it's very possible I'm overlooking something.

@mmahacek
Copy link
Contributor

mmahacek commented Nov 9, 2018

Good point. Though taking it away may cause problems for users that may be integrating it with other systems.

@bdlamprecht
Copy link
Contributor Author

Taking away the slug for device-type would not cause issues with how I'm using it. As that wouldn't have caused the issue I described above to begin with (accidental duplicate slug)

However, removing the slug for device-role would cause HUGE problems for me, so please don't do that.

@cimnine
Copy link
Contributor

cimnine commented Nov 9, 2018

We use the slug usually via the API, as it's neater to refer to than the full names. (And id's are not verbose enough.)

@jeremystretch jeremystretch added status: accepted This issue has been accepted for implementation type: feature Introduction of new functionality to the application and removed status: under review Further discussion is needed to determine this issue's scope and/or implementation labels Nov 28, 2018
@lock lock bot locked as resolved and limited conversation to collaborators Jan 16, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
status: accepted This issue has been accepted for implementation type: feature Introduction of new functionality to the application
Projects
None yet
Development

No branches or pull requests

4 participants