Bugzilla – Full Text Bug Listing
| Summary: | keep repository task editor open after submission, refreshing contents | ||||||
|---|---|---|---|---|---|---|---|
| Product: | z_Archived | Reporter: | Eugene Kuleshov <ekuleshov> | ||||
| Component: | Mylyn | Assignee: | Robert Elves <robert.elves> | ||||
| Status: | RESOLVED FIXED | QA Contact: | |||||
| Severity: | enhancement | ||||||
| Priority: | P3 | CC: | mik.kersten, simcoen, wmitsuda | ||||
| Version: | unspecified | ||||||
| Target Milestone: | 2.0 | ||||||
| Hardware: | PC | ||||||
| OS: | Windows All | ||||||
| Whiteboard: | |||||||
| Attachments: |
|
||||||
|
Description
Eugene Kuleshov
I'm not sure I understand. Do you mean in the "Browser" tab? We don't have a way of controlling that--that's just a bridge to the Web UI. No. This is happening in form editor How does it do that? The current behavior is that after submission the editor closes itselfand I've never seen anything to the contrary. Perhaps you had another editor underneath? Maybe you right. I didn't expect it to close... Will keep an eye on this. I sometimes wonder if it really should close, but it's a bit of work to reset the editor input. Might be less just to reopen after submit, but that will be too wierd. We should reconsider this behavior after 0.5. I think that closing it is really weird. So, as action buttons inside editor. There is already save on toolbar, so you may as well put compare there. Compare could even move to a task list popup menu, and yes, that is a wierd spot for it so we should resolve that as part of this report. Save is tricker--if you hit save it means that you're saving it locally, and that's important. "Submit" is analogous to "Commit" for resources... (In reply to comment #7) > Save is tricker--if you hit save it means that you're saving it locally, and > that's important. "Submit" is analogous to "Commit" for resources... Hmm. It use to be an offline preference that would of cover that if you don't want to publish it to server on save. BTW, there is still weird "mid air change" conflict that is not handled nicely... All of the submission errors (e.g. mid-air collisions) will most likely continue to be handled via the HTML Bugzilla response error dialog until we get the web service UI. It would be too hard and brittle to parse every error bugzilla can return, so we only parse for successful submission. (In reply to comment #9) > All of the submission errors (e.g. mid-air collisions) will most likely > continue to be handled via the HTML Bugzilla response error dialog until we get > the web service UI. It would be too hard and brittle to parse every error > bugzilla can return, so we only parse for successful submission. Can you at least make that dialog resizeable? Also it is unclear what to do. If it is just a new comment then error can be simply ignored or what? Is there any plan on resolving this? I find it very annyoing that for each change done in the editor and submitted to bugzilla the editor closes. I would have to say the same. I often have to perform two actions on a bug (Mark as RESOLVED and then close the bug) and having the editor close after the first one is not the ideal scenario. At least ctrl-shift-F11 makes it easy to reopen the bug. ;) I don't see this getting attention until 1.0. Short term, what if we force the editor to reopen as suggested in comment#5? Personally I would see it as an improvement. Me too, although I must admit I've become so accustomed to this I hardly notice. Rob: to be sure, all that this takes is the ability to reset the input on an editor, right? Hopefull that's straightforward now that you've improved the editor architecture? If so please consider this for 0.9. I'm not sure of the extent of the necessary changes for this one. If editor can't be updated easily I'll go with the re-open option for 0.9 then complete for 1.0. *** Bug 164220 has been marked as a duplicate of this bug. *** +1 to simply reopen the editor and make 90% of people happy :) More complex and elegant solutions can be analyzed for post 1.0. I agree Willian. BTW, can editor close (and then reopen) after submit and synchronization completed? So, there won't be nasty delay between close and reopen... I'll look into this now... Update: Bugzilla editor closes/reopens after submit synchronization. Created attachment 53867 [details]
mylar/context/zip
Any further improvement will happen post 1.0. *** Bug 164985 has been marked as a duplicate of this bug. *** I think we've discussed adding a check box indicating if the editor should be reopened but my current thinking is that this should just be another button something like: [ Submit ] [ Submit and reopen] Just to limit the number of clicks involved in submitting a report. (In reply to comment #26) > I think we've discussed adding a check box indicating if the editor should be > reopened but my current thinking is that this should just be another button > something like: > > [ Submit ] [ Submit and reopen] > > Just to limit the number of clicks involved in submitting a report. I thought it is planned for 2.0M1 to refresh editors without closing them... Would be nice to have that done... not scheduled yet though that I'm aware of. Rob: forget my suggestion of the check box. For 2.0 we really should stop this editor closing, and just reload the editor input. If that ends up being a network operation,the editor can go into a "busy" state like the compare editor currently does. Sounds good I'll try to get this in to 2.0. Committed first pass at this. Give it a try and see what you think. Test It seems like there is much less jumping now, which is really great. Few comments: -- Need to restore focus and scroller states and state of the foldable sections after refreshing form -- It would be neat to use new fancy progress indicator like in Eclipse 3.3M4. -- Opening tasks probably should open stub editor and show progress indicator while fetching/synchronizing task data from the repository -- Reopen report on changes still closing editor (In reply to comment #33) > It seems like there is much less jumping now, which is really great. > Few comments: > -- Need to restore focus and scroller states and state of the foldable sections > after refreshing form Agreed. Created bug#172033. > -- It would be neat to use new fancy progress indicator like in Eclipse 3.3M4. > -- Opening tasks probably should open stub editor and show progress indicator > while fetching/synchronizing task data from the repository Just renamed bug#154396 to make these two explicit and scheduled for 2.0 > -- Reopen report on changes still closing editor Sorry, are you talking about new bug editor here? (In reply to comment #34) > > -- Reopen report on changes still closing editor > Sorry, are you talking about new bug editor here? No, when we have opened editor and task synchronization discover new changes in that task popup dialog brought up and then editor is reopened. Unless I am missing something. Oh good catch. I'll look into that as part of this task. It's a little more involved than I had expected. I've create a new report handling stale editor correctly: bug#172042. Although it is working well on 2.0 M1, it does not work for remote tasks, i.e. which are not on task list. |