Vreman, Peter - Acision wrote: >> Vreman, Peter - Acision wrote: >> >>>>> Change sidebar from a static list and add menu to a nested menu >>>>> structure. Only for the current selected target distro/system the >>>>> operations will be shown. The menu structure will be like the CLI: >>>>> >>>>> Systems >>>>> Add >>>>> Delete >>>>> Poweron >>>>> Poweroff >>>>> Reboot >>>>> Enable PXE >>>>> Change profile >>>>> >>>>> >>>> Grouping the "list" and "add" things together is ok, though I like >>>> >> your >> >>>> original "dashboard" idea for surfacing some commonly used functions >>>> better than this proposal. I also see "edit" missing. >>>> >>>> For instance, on the "systems list" page, we can add something like the >>>> following: >>>> >>>> SYSTEM | (Profile Drop Down with Current Profile Shown) | | (No >>>> Change | Power On | Power Off | Reboot) >>>> SYSTEM | (Profile Drop Down with Current Profile Shown) | (Netboot >>>> Enabled | Disabled) | (No Change | Power On | Power Off | Reboot) >>>> SYSTEM | (Profile Drop Down with Current Profile Shown) | (Netboot >>>> Enabled | Disabled) | (No Change | Power On | Power Off | Reboot) >>>> SYSTEM | (Profile Drop Down with Current Profile Shown) | (Netboot >>>> Enabled | Disabled) | (No Change | Power On | Power Off | Reboot) >>>> SYSTEM | (Profile Drop Down with Current Profile Shown) | (Netboot >>>> Enabled | Disabled) | (No Change | Power On | Power Off | Reboot) >>>> >>>> [ Apply changes button at the bottom ] >>>> >>>> One roadblock with adding import is that it can be /very/ slow, so >>>> that's why it's not present now. The same goes for reposync. >>>> To solve this adequately, we need to build a task engine that can log >>>> the output of background processes. In the future, this is something >>>> I want to enable, as it will also enable folks to run reposync and >>>> import from the XMLRPC API's. >>>> >>>> >>> There are several reasons why I changed to this new proposal: >>> - You can now run an action easier on multiple systems. With a toggle- >>> >> all button all systems are quickly selected. Maybe with an additional >> filter you can first filter and then also use the toggle-all >> >> Ok, I think I understand a bit more. >> >> I'm still a rather visual person so I think I could benefit from seeing >> a rough mockup. If it looks like a 3rd grader did in five minutes in >> mspaint (aka "something like I would draw" I don't care, but it would >> help me tremendously :) >> >> >> >> >>> - A confirmation screen with the affected systems can be given. This is >>> >> better for safety, especially with the power options. The confirmation >> screen can also be used for asking the additional input of values like the >> profile or netboot. >> >> I'm not sure I understand this part either, and is another case where an >> example might help. >> >>> - The pull-down boxes require of mousemovement to set everything correct >>> >>> >> I can agree with limiting scrolling. Could this also not be solved by >> having different tabs when editing things? We could have one tab for >> virt settings, one for network settings, etc, and that way just limit >> the vertical scrolling. >> >> >>> - Normally you want to apply the same action on all systems. Using the >>> >> pull-down boxes this requires manual verification. >> >> I would disagree with the idea that I want to apply the same action to >> all systems. For example, if I'm adding a kernel argument that just one >> system needs, I would be editing just this one system. >> >> Similarly, if I am deciding to reinstall one system that was comprimised >> and/or "really broken" that's something I want to do to just one system. >> >> Also, are you saying the manual verification bits are good or bad? I >> think they are generally a good thing and for wholesale changes I'm more >> likely to write a script or (even more likely) use cobbler find + xargs. >> I realize all users don't fall into that mode, however, so it would be >> nice to have options. >> >>> - With multiple actions in a single apply the confirmation becomes >>> >> complex. >> > > I understand that it is difficult to understand something visual that is > written in text. > > I think it is better that i hack something and submit it for review. > > Peter > > > This e-mail and any attachment is for authorised use by the intended > recipient(s) only. It may contain proprietary material, confidential > information and/or be subject to legal privilege. It should not be copied, > disclosed to, retained or used by, any other party. If you are not an > intended recipient then please promptly delete this e-mail and any attachment > and all copies and inform the sender. Thank you. > > > _______________________________________________ > cobbler mailing list > [email protected] > https://fedorahosted.org/mailman/listinfo/cobbler >
Excellent, I was suggesting the mockup to perhaps limit effort if we decide we want to do something too different, though if you find it easier to just manipulate what's there that's fine. (CobblerWeb.py likely needs some changes to support mass edits in one click, BTW... also be aware of the "systems per page" stuff currently implemented, which is designed to make the Web app scale a bit nicely if there are several hundred or a thosand or so systems in there -- longer term, we want to add search to the webapp on par with "cobbler find") _______________________________________________ cobbler mailing list [email protected] https://fedorahosted.org/mailman/listinfo/cobbler
