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

"Mark Installed" tooltip doesn't properly update to "Mark Planned" #13806

Closed
pv2b opened this issue Sep 18, 2023 · 5 comments
Closed

"Mark Installed" tooltip doesn't properly update to "Mark Planned" #13806

pv2b opened this issue Sep 18, 2023 · 5 comments
Assignees
Labels
severity: low Does not significantly disrupt application functionality, or a workaround is available status: accepted This issue has been accepted for implementation topic: UI/UX User interface or user experience related work type: bug A confirmed report of unexpected behavior in the application

Comments

@pv2b
Copy link
Contributor

pv2b commented Sep 18, 2023

NetBox version

v3.6.1

Python version

3.8

Steps to Reproduce

  1. Go to an enabled non-virtual interface with an installed cable in the device interface view.
  2. Edit the cable and mark it as planned. (Important, do it this way, not through the "mark planned" button.)
  3. Hover over the "mark installed" button, notice that it says "mark installed".
  4. Click the "mark installed" button to mark the cable as installed.
  5. WITHOUT navigating away from the page, hover over the button again and read the tooltip on the button.

Expected Behavior

The tooltip should read "mark planned" since the cable is now marked as installed and the change would be to mark it as planned.

Observed Behavior

The tooltip actually reads "mark installed".

@pv2b pv2b added the type: bug A confirmed report of unexpected behavior in the application label Sep 18, 2023
pv2b added a commit to pv2b/netbox that referenced this issue Sep 18, 2023
Fixes netbox-community#13712 and netbox-community#13806.

Not super happy with the fix here, because it doesn't address the
underlying problem, which is that the toggleConnection() typescript function hardcodes
which CSS classes should be added/removed. Probably a more permanent fix would be
to stop applying CSS classes on the table view, and instead apply attributes
for cable/interface state, and then use CSS to apply colours based on
interface state, but this is a quite involved process. But it does at least
fix things in the here and now.
@pv2b
Copy link
Contributor Author

pv2b commented Sep 18, 2023

I found this bug when working on a fix for #13712, going to send in a fix for this in the same PR

@jeremystretch jeremystretch added status: accepted This issue has been accepted for implementation topic: UI/UX User interface or user experience related work severity: low Does not significantly disrupt application functionality, or a workaround is available labels Sep 21, 2023
@DanSheps DanSheps added status: needs owner This issue is tentatively accepted pending a volunteer committed to its implementation and removed status: accepted This issue has been accepted for implementation labels Jan 23, 2024
@DanSheps
Copy link
Member

Since the previous issue was closed due to a lack of activity, I am putting this back to needs owner for now. If someone would like to take this on, just reply here.

@pv2b
Copy link
Contributor Author

pv2b commented Jan 23, 2024

Hello,

The lack of activity is due to a lack of feedback from the Netbox developer side to my pull requests.

There's a pull request #13874 that's been avaiting maintainer feedback for the last 6 months that addresses this issue.

I also have other pull requests in for the Netbox projects that you have accepted me as an assignee on and then subsequently have seen no review from your side. It's disappointing since I've put effort into the project only for it to get ignored, which means I've not really been interested in contributing more to the project.

I'm happy to work with you on any concerns you have with any of my open issues or PR's, but I won't be contributing anything more until those existing PR's are addressed in some way other than a Github stalebot.

@DanSheps
Copy link
Member

@pv2b I will re-assign you.

In the future, perhaps make sure you make "request review" from at least Jeremy (unless you feel it is better suited for someone else). To be clear, I am not saying this is your fault at all, but it serves as a reminder for the people you request a review of to review it (it also shows in our notifications as a pending review request)

@DanSheps DanSheps added status: accepted This issue has been accepted for implementation and removed status: needs owner This issue is tentatively accepted pending a volunteer committed to its implementation labels Jan 23, 2024
@DanSheps
Copy link
Member

Closed by #13874

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
severity: low Does not significantly disrupt application functionality, or a workaround is available status: accepted This issue has been accepted for implementation topic: UI/UX User interface or user experience related work type: bug A confirmed report of unexpected behavior in the application
Projects
None yet
Development

No branches or pull requests

3 participants