Bug 1730160

Summary:	On edit bug page let user know if bug has updated
Product:	[Community] Bugzilla	Reporter:	Brendan Conoboy <blc>
Component:	User Interface	Assignee:	Jeff Fearn 🐞 <jfearn>
Status:	CLOSED CURRENTRELEASE	QA Contact:	Lianghui Yu <liyu>
Severity:	unspecified	Docs Contact:
Priority:	high
Version:	5.0	CC:	blc, bzhang, jshortt, khong, liyu, nsaddler, qgong
Target Milestone:	5.0-RH7
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:	5.0.4-rh29	Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2019-09-10 22:20:16 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Brendan Conoboy 2019-07-16 02:50:24 UTC

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.

Comment 1 Jeff Fearn 🐞 2019-07-16 03:11:50 UTC

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.

Comment 2 Brendan Conoboy 2019-07-16 20:25:46 UTC

General recycle ability sounds good to me.  Do you offhand have any other suggestions that would achieve a similar result with less effort?

Comment 3 Jeff Fearn 🐞 2019-07-16 22:35:55 UTC

(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.

Comment 4 Brendan Conoboy 2019-07-16 23:10:43 UTC

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?

Comment 5 Jeff Fearn 🐞 2019-07-16 23:24:12 UTC

(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.

Comment 6 Brendan Conoboy 2019-07-17 00:58:32 UTC

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?

Comment 7 Jeff Fearn 🐞 2019-07-17 01:21:34 UTC

(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.

Comment 8 Jeff Fearn 🐞 2019-07-17 01:33:06 UTC

Changing title to better reflect chosen approach

Comment 9 Jeff Fearn 🐞 2019-08-05 03:19:10 UTC

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.

Comment 10 Lianghui Yu 2019-08-09 03:13:48 UTC

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

Comment 12 Jeff Fearn 🐞 2019-09-08 22:18:54 UTC

This change has been deployed to the pre-production infrastructure at https://partner-bugzilla.redhat.com

Comment 13 Jeff Fearn 🐞 2019-09-10 22:20:16 UTC

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.