Below is a new proposal for operations tasks in the webui.
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:
Distros Add Delete Import Systems Add Delete Poweron Poweroff Reboot Enable PXE Change profile Kickstarts Add Rename Delete Copy Profiles Add Delete Rename Copy Repos Add Synchronize Image Add
In the list a check box will be added to mark the systems that need operation. This allows actions on multiple systems.
Thoughts?
Regards, 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.
Vreman, Peter - Acision wrote:
Below is a new proposal for operations tasks in the webui.
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:
Distros
Add Delete Import
Systems
Add Delete Poweron Poweroff Reboot Enable PXE Change profile
Kickstarts
Add Rename Delete Copy
Profiles
Add Delete Rename Copy
Repos
Add Synchronize
Image
Add
In the list a check box will be added to mark the systems that need operation. This allows actions on multiple systems.
Thoughts?
Regards,
Peter
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.
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 cobbler@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/cobbler
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 - 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. - The pull-down boxes require of mousemovement to set everything correct - Normally you want to apply the same action on all systems. Using the pull-down boxes this requires manual verification. - With multiple actions in a single apply the confirmation becomes complex.
Regards, 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.
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.
Regards, 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 cobbler@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/cobbler
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.
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 cobbler@lists.fedorahosted.org 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")
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")
Please find attached an initial hack to show what I mean. Note that the filtering based on the selected item is not done yet.
Comments are welcome.
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@lists.fedorahosted.org