Fix frontend bugs from staging - #447
Merged
Merged
Conversation
The Edit/Delete buttons for a configured Serial Console or Remote Power floated to the left below the table, unlike every other detail tab's Actions sidebar. Restructure into the same two-column row layout used elsewhere (e.g. Manufacturer/Domain detail): the tab title moves inside the content column so it lines up with the "Actions" heading, and Edit/Delete become a proper col-2 sidebar instead of a floated block.
Not up to standards ⛔🔴 Issues
|
| Category | Results |
|---|---|
| Documentation | 7 minor |
| Security | 1 high |
| CodeStyle | 2 minor |
🟢 Metrics 76 complexity · 88 duplication
Metric Results Complexity 76 Duplication 88
🟢 Coverage 100.00% diff coverage · +0.70% coverage variation
Metric Results Coverage variation ✅ +0.70% coverage variation (-1.00%) Diff coverage ✅ 100.00% diff coverage Coverage variation details
Coverable lines Covered lines Coverage Common ancestor commit (010f8af) 24091 18277 75.87% Head commit (6247632) 24590 (+499) 18827 (+550) 76.56% (+0.70%) Coverage variation is the difference between the coverage for the head and common ancestor commits of the pull request branch:
<coverage of head commit> - <coverage of common ancestor commit>Diff coverage details
Coverable lines Covered lines Diff coverage Pull request (#447) 505 505 100.00% Diff coverage is the percentage of lines that are covered by tests out of the coverable lines that the pull request added or modified:
<covered lines added or modified>/<coverable lines added or modified> * 100%
NEW Get contextual insights on your PRs based on Codacy's metrics, along with PR and Jira context, without leaving GitHub. Enable AI reviewer
TIP This summary will be updated as you push new changes.
RemotePowerType.device_count only counted RemotePowerDevice rows, undercounting BMC- and hypervisor-backed usage entirely. Fix the count to consider all three reverse relations (RemotePowerDevice, BMC, RemotePower) - but only the one relevant to a given row's `device` category, since RemotePower.save() mirrors remote_power_device's/bmc's fence_agent onto its own fence_agent field, so naively summing all three double-counts any machine that has both. Also: - Add a device-category filter (BMC/Remote Power Device/Hypervisor) to the Remote Power Type list. - Fix the Remote Power Type detail "Devices" tab, which only ever queried RemotePowerDevice and came up empty for BMC/hypervisor types - now branches by category and links to the actual Machine. - Add a "Machines" tab to RemotePowerDevice's own detail page (it had no way to see which machines used it - remote_power_device uses related_name="+", so there's no ORM reverse relation to browse), and a machine count column to the Remote Power Device list, computed via a correlated subquery since the same related_name="+" blocks a plain Count() through the reverse relation. - Verify the fix holds when a RemotePowerType restricts itself via "Supported Architectures"/"Supported Systems" - unrelated M2M relations that must not interfere with the count via JOIN fan-out.
Both Machine and Enclosure already carry netbox_id (synchronized when > 0), but had no way to filter by it in the list views, unlike Manufacturer/DeviceType. Replicate the existing has_netbox pattern (Yes/No/Clear button group) into MachineListView and EnclosureListView.
None of the "Fetch Netbox"/"Compare data with NetBox" buttons (Machine, Manufacturer, DeviceType, Enclosure, RemotePowerDevice) checked netbox_id before rendering as clickable, even though fetch_netbox()/ compare_netbox() already no-op when netbox_id == 0. Guard both layers: disable the button in the template when unsynced, and early-return with an error message in each view so a bypassed disabled state can't queue a no-op task either.
TFTP Server was rendered as plain text unlike Cobbler/CScreen Server, which already link to the machine. Also the detail footer only had an "Edit:" link, missing the "API:" link every other recently-redone detail page has - reuse the existing DomainInfoCommand (api:domain).
Machine.vm_max is required, but edit_machine.html only renders the hypervisor-only fields for systems with allowHypervisor=True. On other systems the browser never submits vm_max, so any edit (e.g. toggling "administrative") silently failed validation with no visible error.
Editing is now surfaced exclusively through the "Edit" button already present in each detail page's Actions sidebar. Machine was the one entity missing that button, so it gets a superuser-gated one.
SchoolGuy
force-pushed
the
fix/arch-test-frontend-bugs
branch
from
August 22, 2026 12:32
9834780 to
6247632
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
After working with the newly deployed version of Orthos 2 in the internal staging instance, I discovered a few bugs that had to be fixed. See the individual commits for details.