Community
Participate
Working Groups
We currently have a form-based Bugzilla editor and local task info editors. Once we have common task attributes (bug 138041) the Bugzilla editor should be pulled up to tasklist, and connector-specific editors can subclass that.
Proposed "Save" cycle, based on current Bugzilla editor: - "Save" action stores a report offline, marks it with ougoing state - At the bottom of an editor, and potentially in the popup for the Task List view, we have the following actions: * Submit to Repository * Override * Compare Proposed "Open" cycle: - Always open offline copy (fast) - Kick off a background synch, offer to re-load editor if changes exist
I still convinced that current bubzilla submit buttons somehow weird. How about add Mylar task list model and use Synchronize view to push all the work and review incoming changes to the task list? It seems hard to see what new is getting in for given query, since task list is not exactly designed to make it easier to see. Synchronize view would also be great idea to use for the offline mode... Another idea for the following section, which doesn't really belong to the isue editor. ( ) Leave as NEW ( ) Accept bug (change status to ASSIGNED) ( ) Resolve bug, changing resolution to [________] ( ) Resolve bug, mark it as duplicate of bug # [____] ( ) Reassign bug to [_______] ( ) Reassign bug to default assignee and QA contact of selected component [ Commit ] Why don't have an additional action (on toolbar and right from the task list), that would bring this form in a dialog and will also allow to type a comment. Jazz actually something like this.
From https://bugs.eclipse.org/bugs/show_bug.cgi?id=133764#c27 (In reply to comment #27) > Regarding scrollbars, yes, I think that it's key not to force using multiple > scrollbars on one editor. So we have to either choose the current JIRA form > way of doing it: collapsible sections top and bottom, scrolling comment section > in the middle, or our current way with big scrolling page. +1 for having single scrollbar similar to current Bugzilla editor. Collapsable areas a requite confising and does not work well when there are lot of comments with large stack traces, etc. Not to mention that at some point we may get to printing those reports...
Created attachment 43367 [details] Overview tab of the Jazz issue editor
Created attachment 43368 [details] Links tab of the Jazz issue editor
Created attachment 43370 [details] Another look at overview tab of the Jazz issue editor There are few intersting findings used in Jazz issue editor (see this and other attachments). -- issue id at the top (though it could have reporter's name, creation and last update dates out there) -- next line has description, status and resolution fields (notice that it does not have label for "summary" comparing to the current bugzilla editor) -- issue details are nicely arranged in the left side bar -- all details about attachements and other linked stuff such as version control changesets are in Links tab, which is referenced from the Summary section in the Overview tab. I believe those are interesting findings and it would be nice if they are reflected in Mylar's common issue editor too. What I not quite like about Jazz editor that it is using nested scroll panel for comments. I think Mylar's approach used in Bugzilla editor with single scroller across description/comments list/new comment box is more convenient. Though it could use right side gutter area to help navigate between different editor sections, such as description, comments and new comment areas.
Created attachment 43821 [details] mylar/context/zip common editor refactoring
A major portion of the refactoring is done. Work remaining includes cleanup of the layout (perhaps change how custom attributes are added to the form), change 'description' to attributes in outline, tidy up the code and fix java doc. In addition we should look into use of the new bug editor. Perhaps we can use a single bug editor for both new and old bugs. With some alterations ExistingBugEditorInput could probably be used for both existing and new reports. I have not yet addressed the layout/command ideas mentioned above by Eugene.
Nice work Rob. I fixed up some of the naming and deleted old code/docs to get rid of the bugzilla refs.
By the way, can you also do something about this annoying popup about new updates in editor which then close and reopen editor (lots of flickering). I wonder if you can use special panel (like firefox search bar) at the top of editor window and put all event notification up there to make it less distracting and non modal. It should also not close editor, but try to update everything in place.
As it its the dialog mimics what happens when a resource is modified outside of the workbench. Comments related to alternative notification and editor updating of the editors can be brought up on bug# 142039.
(In reply to comment #11) > As it its the dialog mimics what happens when a resource is modified outside of > the workbench. Comments related to alternative notification and editor updating > of the editors can be brought up on bug# 142039. The thing is that resource can be manually backed up, which won't be possible with the bug editor.
The original intent of this report has been resolved so marking as such. We will open new reports for specific nits as they arise.
