Hide Forgot
Description of problem: In the RHEL products, every time a new RHEL BZ is created some BRE rules run which update flags. This update typically happens within a couple seconds of the BZ being created. This presents the end user who created a BZ with a version of the BZ which does not yet have the results of the BRE run in their display. If they go to edit the bug they will invariably find there is a collision. This is a problem. As we increase the use of BRE in RHEL we are finding and creating more examples of this problem. A recent example is that when users set the blocker? or exception? flag BRE now appends a template for them to fill out to explain why it should be a blocker or exception. Users don't see this template until they manually reload the BZ or check their email. So the RFE is as follows: When a BZ is created or updated, give BRE a chance to run before displaying the updated page. If BRE takes longer than a short timeout (5 seconds? 10 seconds?) go ahead and redisplay the page. Or, alternately, if BZ has the ability to detect an update behind the scenes and convey that to the user either by a notice or updating the contents of the displayed bz in realtime, that would be acceptable. There might be other sensible approaches, too. The end goal is the same: Show users the end result of automation so they can work with the automation smoothly and interactively, without having to remember to hit reload.
The option to run this before the user gets the updated page is not possible with the current design. We would have to do a major rewrite to allow this. Even then it would be unreliable as the user has to receive the completed page within 120 seconds; with a large number of rules in place it may not be possible to complete the full bug update + BRE run within that time limit and the user would see a 500 proxy error. It is not possible to partially couple these to do a timeout for the UI and not timeout the related BRE changes as they would all be occurring in the same thread and database transaction. The second approach would probably be best done with web-sockets, it would require us to create javascript to update the web page. This would require a reasonable effort to implement, but less that the first approach. It would also be usable for changes made via the APIs or by other users, so has a broader effect and better ROI.
General recycle ability sounds good to me. Do you offhand have any other suggestions that would achieve a similar result with less effort?
(In reply to Brendan Conoboy from comment #2) > General recycle ability sounds good to me. Do you offhand have any other > suggestions that would achieve a similar result with less effort? Nothing comes to mind. The BRE has some goals that conflict with it running in the change transaction. Specifically the periodical run type, and the looping nature of the rule check. So making it work in the users transaction without removing those two features is complex. A simpler way to do the UI update would be to poll via ajax to see if the bug has changed. We'd still need to do the javascript to update the UI but it would be almost entirely client side and not require many backend changes, which could reduce the effort required by a reasonable margin.
This sounds related to the request to do dynamic page updates when the custom Internal Target Milestone field has dynamic entries based on the content of Internal Target Milestone. Does it make sense to combine this there?
(In reply to Brendan Conoboy from comment #4) > This sounds related to the request to do dynamic page updates when the > custom Internal Target Milestone field has dynamic entries based on the > content of Internal Target Milestone. Does it make sense to combine this > there? I'm guessing you typo'd a field name there, but IIRC that feature was to be presented to the user before they save a change? If so that is not related.
I'm probably conflating two javascript-based features, so let's ignore comment 4 :-) It sounds like you have an approach that will work for the request and might also advance some other requests and objectives. Do you need anything else spec-wise from me to move forward with this request subject to prioritization?
(In reply to Brendan Conoboy from comment #6) > I'm probably conflating two javascript-based features, so let's ignore > comment 4 :-) It sounds like you have an approach that will work for the > request and might also advance some other requests and objectives. Do you > need anything else spec-wise from me to move forward with this request > subject to prioritization? It shouid be good to go.
Changing title to better reflect chosen approach
I've decided to do this very simply and mimic how Gerrit does it. When a bug is updated it will display a message letting the user know the bug has updated and offer the user two links. One to reload the page and one to ignore the update. The message is non-modal so the user can completely ignore if they want.
Verified on latest QE environment. There is a pop up widget "This bug has been updated" to notify user, works well on rule engine changes. But it is a little bit tricky, when a user updated the bug but page didn't reload in time, this will also pop up for current user. Result: PASS
This change has been deployed to the pre-production infrastructure at https://partner-bugzilla.redhat.com
This change is now live. If there are any issues, do not reopen this bug. Instead, you should create a new bug and reference this bug.