Skip to content

Cable connection fails if Rack value is deleted and only uses Site and Device values #4111

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

Closed
JerradGit opened this issue Feb 6, 2020 · 2 comments

Comments

@JerradGit
Copy link

Environment

  • Python version: 3.6.9
  • NetBox version: 2.7.4

Steps to Reproduce

  1. Select any Device which has a Front Port, Rear Port, Interface, or Console Port
  2. Connect a cable (Front Port, Rear Port, Interface, or Console Server Port) it doesn't matter
  3. When the connection window displays, on the B Side, remove the auto populated rack name so that only the Site field remains populated
  4. Choose a device from the Device drop down
  5. Make a selection from the Name field to connect this cable to
  6. Click on Connect

Expected Behavior

I expect a new cable to be created and be returned back to the device page with the Created cable notification

Observed Behavior

An error message is returned to the UI with the message "Select a valid choice. That choice is not one of the available choices." directly below the Device field.

Before clicking Connect
image

After Clicking Connect
image

If I follow the same steps, but also delete the auto populated Site name in addition to the rack name the procedure works as expected.
image
image

If on the other hand you know which rack the device is in and select that rack first before selecting the Device it also works.

There are two old issues which I think are related to this
#3999
#3310

3310 automatically populates Site/Rack name now, so any time you need to connect a cable to a device which isn't in the same rack you need to delete the rack or choose a different one before the Device field will present values to choose from which is how I discovered this.

@hSaria
Copy link
Contributor

hSaria commented Feb 10, 2020

This is fixed indirectly with #3912.

@jeremystretch
Copy link
Member

Just merged a PR for #3912 and I can confirm that this is no longer a problem. It will be resolved in v2.7.5.

@lock lock bot locked as resolved and limited conversation to collaborators May 20, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants