The top half of the system details page is a confusing mix of information about the system (updated by clicking the Edit Details page) and various actions that can be taken *with* the system (like loaning, reserving, changing the owner, contacting the owner, and updating the notify CC list). It would be better to separate these out more clearly. It would also be nice to do something about the proliferation of tabs on the systems page, but that's beyond the scope of this RFE.
A few more specific ideas/questions: * The read only view shouldn't use faded out text edit boxes to display data. * Owner, current user, loaned to and notify cc should be in a separate block below the system information * The NDA flag should be displayed as a checkbox in the read-only as well as the Edit view * Rather than displaying Lab Controller and Location separately, perhaps they could be displayed more concisely as a single field: beaker-lc.site.example.com (Example location) * Perhaps the edit view should become a bootstrap modal instead of a separate page? * Perhaps it would make sense to move some of the existing fields in the top half of the page down into the "Details" tab? Primarily thinking of Vendor, Lender and Serial Number, but perhaps Mac Address as well. Main challenge with this idea is what to do about the editing UI (so perhaps worth skipping for now)
(In reply to Nick Coghlan from comment #1) I like all your suggestions, just some comments on this bit: > * Perhaps it would make sense to move some of the existing fields in the top > half of the page down into the "Details" tab? Primarily thinking of Vendor, > Lender and Serial Number, but perhaps Mac Address as well. Main challenge > with this idea is what to do about the editing UI (so perhaps worth skipping > for now) Vendor and Model are interesting ones because they are the only fields which are both editable by the system owner and also updated by the inventory script. Serial Number and MAC Address could also be updated by the inventory script but it doesn't have the necessary smarts at present. So all of those fields could reasonably be said to belong in the Details tab. The rest of the hardware info on the Details tab is currently not editable, but only because nobody has written a UI for it (there is a very old RFE for it somewhere). Lender, on the other hand, is completely unrelated to hardware details and should not be treated as such.
*** Bug 1015100 has been marked as a duplicate of this bug. ***
Bumping the priority on this to be addressed in 0.15.1 (since it's just UI updates, no db changes)
The improved system page UI as discussed here: http://thread.gmane.org/gmane.comp.systems.beaker.devel/912 is now fully implemented, with one exception: there is no search bar for the system activity grid (I'm still not sure what to do about that, suggestions welcome). Patches are on Gerrit targetting the new-system-page branch: http://gerrit.beaker-project.org/#/q/project:beaker+branch:new-system-page,n,z
I've been considering how best to communicate this change to users before we land it in a release (that is, I don't think we can wait and just explain it in the release notes of whichever release it lands in - we need to introduce people to the updated workflows well in advance of that happening). I'm currently thinking of the following approach: - before we include it in a release, we create an after-the-fact design proposal on beaker-project.org that describes the key changes and the rationale behind each of them. This design proposal should also point out the command line additions made in 0.15 to avoid the need to screen scrape the web UI for operations and information previously not available through the bkr CLI. This would need a one or two screenshots to provide a before-and-after comparison relative to Beaker 0.14, but wouldn't need to provide screenshots for everything. - when we include it in a release, we also include a task-oriented update to the documentation of the system page that explains the various workflows it supports - after we include it in a release, we get Fedora to upgrade their test instance, and then use that to create a screencast we can post on beaker-project.org covering the various updated workflows. This could be done as a general introduction to the Beaker system page, so it's hopefully useful for new users as well as to users that will be migrating from the existing system page
After-the-fact design proposal is here: http://beaker-project.org/dev/proposals/system-page-improvements.html
A demo Beaker instance based on the new-system-page branch is running here, for people to experiment with the modified UI: http://209.132.179.159/bkr/ Username is "demo", password is "demo".
(In reply to Dan Callaghan from comment #5) > The improved system page UI as discussed here: > > http://thread.gmane.org/gmane.comp.systems.beaker.devel/912 > > is now fully implemented, with one exception: there is no search bar for the > system activity grid (I'm still not sure what to do about that, suggestions > welcome). This last missing piece of the puzzle is now done: http://gerrit.beaker-project.org/3328 http://gerrit.beaker-project.org/3329 http://gerrit.beaker-project.org/3330 http://gerrit.beaker-project.org/3331
*** Bug 1086508 has been marked as a duplicate of this bug. ***
The new-system-page branch has been merged back to develop. Any remaining bugs/improvements relating to the system page will be filed as new bugs against 'develop' version, rather than prolonging this bug.
Beaker 19.0 has been released.