RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 617586 - Implement progress dialog for long-running operations
Summary: Implement progress dialog for long-running operations
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: luci
Version: 6.0
Hardware: All
OS: Linux
low
medium
Target Milestone: rc
: 6.1
Assignee: Ryan McCabe
QA Contact: Cluster QE
URL:
Whiteboard:
Depends On:
Blocks: 617587
TreeView+ depends on / blocked
 
Reported: 2010-07-23 13:41 UTC by Andrew Beekhof
Modified: 2016-04-26 15:23 UTC (History)
5 users (show)

Fixed In Version: luci-0.23.0-12.el6
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2011-05-19 13:56:10 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2011:0655 0 normal SHIPPED_LIVE luci bug fix update 2011-05-19 09:47:45 UTC

Description Andrew Beekhof 2010-07-23 13:41:43 UTC
Description of problem:

Many operations (create cluster, add/remove node, online/offline node) require refreshes.
Yes there is one in the browser, but updating is a common gui operation and it's very jarring to repeatedly "leave" the gui to accomplish this task.

Version-Release number of selected component (if applicable):

luci-0.22.2-1.auto1279839662

Comment 2 RHEL Program Management 2010-07-23 13:57:49 UTC
This issue has been proposed when we are only considering blocker
issues in the current Red Hat Enterprise Linux release.

** If you would still like this issue considered for the current
release, ask your support representative to file as a blocker on
your behalf. Otherwise ask that it be considered for the next
Red Hat Enterprise Linux release. **

Comment 3 Chris Feist 2010-08-03 14:16:44 UTC
Not sure that this makes sense to do if the user can just hit the refresh button at the top of the screen.  We'll need to talk to the design people and see what they feel would be best.  Bumping to 6.1 since this isn't critical for 6.0.

Comment 5 Jan Pokorný [poki] 2010-09-13 21:05:30 UTC
Looking from both user and programmer perspective, I can imagine that:
1) for each action that requires refresh the most suitable (let's say typical+reserve time) period is found
2) using JavaScript, after the page is loaded, the timer is set to this value and then visually counted down and when it reaches 0, it will trigger page reload automatically
3) near this visual counter, there will be also link-like (somehow highlighted to notify user it can be clicked) label "refresh immediately" or something like this

For this purpose, flash2 component could be extended for this kind of messages.

More challenging idea would be to keep displaying "busy message" until the underlying code really finished what expected. But this sounds like overkill, maybe even impossible with existing design.

Comment 6 Jan Pokorný [poki] 2010-09-14 15:26:43 UTC
(In reply to comment #5)
The previous applies e.g. to creating cluster (mentioned in bug description), which really wants user to reload the page on its own to continue. Contrary, there are situations where page reload only serves to remove "message box".


The example of this can be node addition (also mentioned in bug description), after which the fully working GUI is shown. It is true that very visible place within this GUI is covered with the message box informing about such action (node adition) and that this panel can be annoying once it is read, but this could be easily addressed with a "hide" button placed inside this panel that would be able to remove the whole message box (-> no need to reload the page to get rid of that box).

There are currently two ways to achieve the above (see [1], section "basic UI components"):
1. using WebFlash component integrated to TurboGears2
2. using flash2 component which is own work and thus more flexible (in term of customization)

Comment 19 errata-xmlrpc 2011-05-19 13:56:10 UTC
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on therefore solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHBA-2011-0655.html


Note You need to log in before you can comment on or make changes to this bug.