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

PATCH requests to cable-terminations do not update the old endpoint #12023

Closed
SheffSix opened this issue Mar 21, 2023 · 4 comments · Fixed by #13337
Closed

PATCH requests to cable-terminations do not update the old endpoint #12023

SheffSix opened this issue Mar 21, 2023 · 4 comments · Fixed by #13337
Labels
severity: medium Results in substantial degraded or broken functionality for specfic workflows status: accepted This issue has been accepted for implementation topic: cabling type: bug A confirmed report of unexpected behavior in the application

Comments

@SheffSix
Copy link

NetBox version

v3.4.6

Python version

3.8

Steps to Reproduce

I came across bug #11901 (although I am working with front ports not interfaces), and had the idea of sending the PATCH/PUT to /dcim/cable-terminations/{id} directly instead of the cable.

The results are an imporovement, but still has to problem that the old endpoint still thinks it is connected to the cable.

Steps to reproduce:

  • create three devices
  • Create three rear ports and three front ports, one of each for each device
  • create a cable connection between two of the devices' front ports
  • request an API PATCH HTTP request to change the device and port of b termination to the third device.

Expected Behavior

The cable is moved from port two to port three, and there are no references to the cable on port two

Observed Behavior

Looking at the properties of the cable, it shows that it is connected to ports one and three as expected.

However, from the front port view, port two still reports as being connected to the cable as well as ports one and three.

@SheffSix SheffSix added the type: bug A confirmed report of unexpected behavior in the application label Mar 21, 2023
@jozefws
Copy link

jozefws commented Mar 24, 2023

Duplicate of #11901 :)

@jeremystretch jeremystretch added the status: needs owner This issue is tentatively accepted pending a volunteer committed to its implementation label May 4, 2023
@jeremystretch jeremystretch added the severity: medium Results in substantial degraded or broken functionality for specfic workflows label Jun 23, 2023
@jsenecal
Copy link
Contributor

jsenecal commented Jul 5, 2023

Duplicate of #11901 :)

It is not.

@arthanson arthanson self-assigned this Sep 5, 2023
@arthanson arthanson removed the status: needs owner This issue is tentatively accepted pending a volunteer committed to its implementation label Sep 5, 2023
@arthanson
Copy link
Collaborator

I repro #11901 but not this one, regardless I think #13337 will fix this as well.

@DanSheps DanSheps added the status: accepted This issue has been accepted for implementation label Sep 7, 2023
@jeremystretch
Copy link
Member

I was not able to reproduce this on v3.6.2 (prior to the merger of PR #13337). It was likely resolved by some other change in a more recent release.

@github-actions github-actions bot locked as resolved and limited conversation to collaborators Dec 26, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
severity: medium Results in substantial degraded or broken functionality for specfic workflows status: accepted This issue has been accepted for implementation topic: cabling type: bug A confirmed report of unexpected behavior in the application
Projects
None yet
Development

Successfully merging a pull request may close this issue.

6 participants