Bugzilla – Full Text Bug Listing
| Summary: | Form based editor for Jira tasks | ||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | z_Archived | Reporter: | Eugene Kuleshov <ekuleshov> | ||||||||||||
| Component: | Mylyn | Assignee: | Brock Janiczak <brockj> | ||||||||||||
| Status: | RESOLVED FIXED | QA Contact: | |||||||||||||
| Severity: | enhancement | ||||||||||||||
| Priority: | P4 | CC: | brockj, mik.kersten, robert.elves | ||||||||||||
| Version: | unspecified | ||||||||||||||
| Target Milestone: | 0.6 | ||||||||||||||
| Hardware: | All | ||||||||||||||
| OS: | All | ||||||||||||||
| Whiteboard: | |||||||||||||||
| Bug Depends on: | 139320 | ||||||||||||||
| Bug Blocks: | |||||||||||||||
| Attachments: |
|
||||||||||||||
|
Description
Eugene Kuleshov
Created attachment 38655 [details]
Jira form based editor
I have attached a screenshot of the form based editor i had planned to add to Jira Dashboard. It does work, but the content contains HTML markup, which makes it look really ugly. There is a new remote API to get the comments of an issue, but it would mean upping the required Jira version (quite a bit) and writing a Confluecne wiki to Styled Text converter.
Looks ok to me. Two comments though. -- In general, it is probably unnecessary to match web UI. Hoewer it seem make a good use of the editor width. I wonder if Bugzilla editor should also use column at the left to show important issue attributes. -- Those html tags they created by Jira from wiki formattings. So, it perhaps very limited subset that can be converted to the styled text. At least things like <br>, & masking, etc. I like the layout, assuming that it doesn't result in too much scrolling. The nice thing with forms is that it will be possible to support both a two and a one column layout. We are about to start generalizing the Bugzilla editor to be in tasklist, so that it works for any connector. This will happen in conjunction with making tasks a collection of generic attributes, comment thread, and actions, which will mean that JIRA issues will get the same offline and synchronization support that we currently have for Bugzilla, and the current editor will work for them. Eugene has also suggested that we use the two-column format which seems like it could improve density (bug 137627). It's a little unfortunate that we seem to be gravitating to having two seperate UIs for working with JIRA issues. I hope that by Mylar 0.6 or so we have enough in place that you consider extending it, but I understand that for now you want to keep pushing on the JIRA dashboard UI. (In reply to comment #3) Mik, Brock, does this mean that form-based Jira editor and offline features for Jira will be put on hold until Mylar 0.6? Nope, tentative plan is to have it in 0.5.2: http://www.eclipse.org/mylar/plan.php The 0.6 milestone is misleading, because it's meant to indicate by 0.6.0. I'm thinking about changing the milestones to have minor minor numbers (e.g. 0.5.1, 0.5.2, 0.6.0) to address this. But I also wonder if/when to consider the switch to the platform Milestone convention. Brock: just curious, what's the code for putting the "Direction" button on the section separator? I think we should put our "Expand All Comments" there. The call is Section#setTextClient(Control) The editor is in jira.ui: org.tigris.jira.internal.ui.tracker.editor.JiraIssueEditor2 (In reply to comment #7) > The call is Section#setTextClient(Control) > > The editor is in jira.ui: > org.tigris.jira.internal.ui.tracker.editor.JiraIssueEditor2 Brock, are you going to contribute it for Mylar? I.e. attach some patch here would make it easier from legal aspects. Just in case I'll have time to mess around with it... Created attachment 41397 [details]
Jira editor integrated into mylar
Screenshot of the jira editor integrated into Jira.
Remaining items:
- Add missing icons
- Remove all actions on the left
Everything should be done this weekend
Wow!! This will set us up perfectly for the common editor and offline storage which we hope to start on next week... Not to mention that we've been getting very significant JIRA connector downloads so people should be happy :) Check out download-stats.xls if you're curious. Rob: we can start by making the common edtitor a lowest-common denominiator between the Bugzilla and Brock's JIRA editor (just comments and attributes/details), then think about generalizing the operations. (In reply to comment #9) > Screenshot of the jira editor integrated into Jira. > > Remaining items: > - Add missing icons > - Remove all actions on the left > > Everything should be done this weekend That is cool. One suggestion though. Please don't make separate scrollbars for each section. It is more convenient to either see whole section or collapse it when not needed. Bugzilla editor is quite ballanced from this point of view. Created attachment 41432 [details]
patch to org.eclipse.mylar.jira
This patch has only had a small amount of testing. I had to add the issue key to JiraTask, so all previously saved tasks will fail to restore.
The copyright headers are probably wrong and some classes could be named better (JiraIssueEditorInput and JiraIssueContentOutlinePage)
So it's sounding like JIRA uses the int-based key to uniqely identify the issue (and hence an issue can end up with two keys if it is moved). Mylar relies on a single unique way of identifying each report. Otherwise contexts can get mixed up, and tasks that appear in two queries seem different when they are the same task. Is there any way that we could avoid the key field and keep using the int id for jira issues? Or do is there a problem with retrieving a jira issue given the int id only? It looks like you can get an issue by id: http://www.atlassian.com/software/jira/docs/api/rpc-jira-plugin/latest/com/atlassian/jira/rpc/soap/JiraSoapService.html But it would mean increasing the minimum supported jira version to 3.5. Apache is running 3.5, but Codehaus isn't. I don't have a 3.5 environment either :) Let me know if you do want an API to get an issue by id. It shouldn't take too long to hack something up. The service won't perform very well because it will need to make two trips to the server due to a poor design decision on my part. Seems that we should continue support 3.3.1 if at all possible (I assume the API you're proposing would be 3.5 only). Rewinding a bit, do we really need the key field? We can always get the ID if we have the issue, and can get the issue given a key. So I wonder if we can always look it up from the task list, and simply not support adding issues by ID, only by key? yes the api would only work in 3.5. Older version go though the web interface to load issues which only knows about keys. The problem i had was finding the issue for a given task. The task stores a handle so you can reconstuct the issue object from it. Unfortunately, given the current API available, we can't find the issue from the ID, we need the key. Brock, I have applied the patch. I left the key field and externalization for JiraTask, but made the failure to restore graceful so that old tasks still work. Opening an editor should always work because we always synchronize the task before opening it. Other than that I only made minor warnings clean-up, generics changes, and improved error handling. Note that I also added an issue for testing: JDB-100: test Mylar editor integration http://developer.atlassian.com/jira/browse/JDB-100 So we're looking good for having this as an experimental feature in Friday's 0.5.2! It looks like the outstanding items are: - making the Summary items editable (or were you thinking of putting in the "Operations" section in the screenshot, since they seem to server a similar purpose?) - consitentcy with our bug editor - offline support Btw, are you going to be using this integration? This may shock you, but i don't actually use Mylar and hardly ever use Jira anymore :) The sidebar looked cool, but it is a waste of space. I am not quite sure what to do about the editable fields yet. I prefer wizards as it forces the user to edit only the fields that are valid for the task they are trying to achieve which helps prevents accidental changes. Some actions (like attaching a file or screenshot) will need a wizard anyway. Perhaps the summary, description, priority, component and version fields should be directly editable and the rest done via wizards? If you don't use Mylar or JIRA, what issue tracker and task mangement integration do you use? Or how do you managet to be so productive without that? ;) Agreed about the sidebar being a waste of space. Our Bugzilla editor only permits editing of valid fields with valid values via combo boxes, so perhpas we can do that once we start merging. We're also going to support attaching with a simple file chooser, but yup, fancier stuff could involve launching a wizard. I'm hoping that for the fileds you point out, and a couple of others, this extra UI complexity is not necessary. I've made a new bug 142869 where we can discuss that. Anyway the core of this is now working and additional bugs and enhancements should be new reports. Thanks again for the great contribution Brock! We should get some good mileage on it in 0.5.2. Created attachment 42096 [details]
mylar/context/zip
Done. Strange to see that issue is closed. The currently released thins is nowhere an editor because it is not possible to edit anything at all. I also disagree that sidebar is a waste and truly believe quite opposite that attributes section is real waste, since I can't see any comments at all because that section takes nearly entire height of the first editor page. From other hand I have 1/3 of width unused as I already mentioned before, so sidebar (perhaps collapsable one) would be a perfect fit to fill this area wwith something useful. Created attachment 42132 [details]
Layout of the issue editor from Jazz project
Here is what one could expect to see from the nice issue editor. Sorry for the screenshot quality.
I particulary like how description, issue status and resolution laid out and arrangement of the dropdowns on the left side.
Also note gutter for on comments area, which has this fancy popup that show info about commenter, including task he is currently working on.
Bottom left corner of the editor shows links to attachments and related change sets. It would be interesting to link this information as well. Should be not an issue with svn and perhaps can be somehow worked around for cvs.
That is really nice, but they have a paid team working on it :) I really like how they used a single text editor with an overview bar for the comments. It would make navigation very easy and remove the need for the outline view. Does Jazz support multiple issue and code repository types? The issue fields and workflow transitions would be very different for Jira (ie. handling custom workflows) What's currently possible is posting new comments. I've made that clear in the New & Noteworthy, and made the limitations more explicit. There are two reasons why I closed this report: 1) the core functionality is there, and we can now build additional features on it each with its own report and discussion, and 2) to give Brock credit for this in case he doesn't have time to contribute those other enhancements. We were really tempted to use the single editor for comments. What stopped us is losing some individual control over the comments, e.g. the straightforward collapse that we have now (folding of a single editor is more complicated). But more importantly the seperate comments will allow us to render comments using the Browser widget, which is what I assume that we want for JIRA? I was also thinking that it could be neat to render Bugzilla comments with at Wiki rendering widget... (In reply to comment #25) > What's currently possible is posting new comments. I've made that clear in the > New & Noteworthy, and made the limitations more explicit. I see. It is big confusing actually to submit changes on save, but probably the right way of doung it comparing to "submit" button in bugzilla editor. I guess it would be a good idea to save task changes locally and submit in the background when online, otherwise have action "submit" or "puch changes" in the Task List view, which will be similar to Team Synchronize view > There are two reasons why I closed this report: 1) the core functionality is > there, and we can now build additional features on it each with its own report > and discussion, and 2) to give Brock credit for this in case he doesn't have > time to contribute those other enhancements. Ok. That makes sense. I'll open few reports about outstanding issues. > We were really tempted to use the single editor for comments. What stopped us > is losing some individual control over the comments, e.g. the straightforward > collapse that we have now (folding of a single editor is more complicated). Hmm. I thought that platform have some support for that. And it is more natural to have collapse controls in the left gutter. Though it won't work if there is a sidebar. Another bad thing about Jazz's editor and current Jira editor is the scrollers. It seem more convenient to have a single scroller for the entire editor like it is done in Bugzilla editor > But more importantly the seperate comments will allow us to render comments > using the Browser widget, which is what I assume that we want for JIRA? Do we really? I believe it is heavier and can be pretty much simulated by styled text. There should be some code in platform for doing this. As far as I recall tooltips in java editors are used to be doen in styled text (I really hate new browser widget based tooltips on F2 that have been introduced not a long time ago). Note that with browser widget you can't use keyboard navigation to select text. > I was also thinking that it could be neat to render Bugzilla comments > with at Wiki rendering widget... Does jira return wiki formatting? I thought that once submitted it can't be read back. 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. Comments on this would probably be best on bug 138043. Regarding the browser formatting, as far as I know in an editor you can only hovera Browser widget, can't embed it. It seems to be like we're not quite supporting JIRA and other repositories with the ability to have rich comments if we do not render them. But yes, there are tradeoffs and we could support both. My comments on posting are going on bug 138043. |