|Issue 1739||Notify bug reader of activity after bug was displayed|
|Starred by 5 users||Project Member Reported by elawre...@chromium.org, Aug 31 2016||Back to list|
What steps will reproduce the problem? (1) Visit a bug. (2) Spend 30 minutes investigating it. (3) Carefully type your findings in the bug as you go. (4) Click Save. (5) Observe: Your findings appear below the same findings from some smarter dev who figured this out 25 minutes ago and already resolved the bug. What is the expected output? Less sadness. Some sort of notification like "This bug has been modified. Click here to reload?" or "Click here to show latest messages". Google Groups does this pretty well.
Aug 31 2016,
Yep, this is a feature we'd really like to do, but won't really be feasible until we're working on a larger UI overhaul. Putting in the appropriate milestone.
Sep 15 2016,
Here's how I'm working around now: https://chrome.google.com/webstore/detail/crbug-watcher/cfhjlnjlcagociccoddecmnmphopaahk The biggest worry is the performance cost; if there were a lightweight API endpoint that just took an issue ID and returned a revisionNumber or commentCount, I'd love to use that.
No such API exists; it wouldn't be hard to create. It also wouldn't fully resolve your use-case. For example, if the latest comments are all comment-only (no metadata updates) then they won't conflict with your update. In addition, you'd need a way to refresh the page to show those comments without losing the in-progress comments/changes, which is going to be really hard until the page is reasonably polymerized.
Re #3: I'm interested in all conflicts, not just literal/technical conflicts For instance, you can add textual comment #3 without metadata changes and I can add textual comment #4 without metadata changes-- that may not be technically a conflict, but it's a "conflict" in the sense defined in my original Issue report-- I wasted time doing work on something that I didn't need to do. I think the existing Monorail API (https://apis-explorer.appspot.com/apis-explorer/?base=https://monorail-prod.appspot.com/_ah/api#p/monorail/v1/monorail.issues.comments.list) offers what I need, but I haven't yet poked at it to understand how the Auth Token thing works. My extension currently detects new comments and it simply injects the HTML of the newly discovered comments into the DOM at the appropriate place. This seems to work reasonably well for my use-case.
I am thinking that I need to add this feature to Monorail now, even if that means doing double work to get it in polymer later. If I can get that done, you won't need an extension. The reason for my change in prioritization is that I need to implement some kind of polling while the user edits an issue to support indications of issue owner availability (e.g., "the issue owner that you just selected has not visited the site in 39 days") in issue 2052. As long as I am going to implement that, I could piggy back this feature onto it. I'll try to add a brief design doc to that issue soon.
|► Sign in to add a comment|