Bugzilla – Full Text Bug Listing
| Summary: | add option to submit context with bug report | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | z_Archived | Reporter: | Mik Kersten <mik.kersten> | ||||||||
| Component: | Mylyn | Assignee: | Jeff Pound <jeff.bagu> | ||||||||
| Status: | RESOLVED FIXED | QA Contact: | |||||||||
| Severity: | enhancement | ||||||||||
| Priority: | P2 | CC: | ekuleshov, steffen.pingel | ||||||||
| Version: | unspecified | ||||||||||
| Target Milestone: | --- | ||||||||||
| Hardware: | PC | ||||||||||
| OS: | Windows XP | ||||||||||
| Whiteboard: | |||||||||||
| Attachments: |
|
||||||||||
|
Description
Mik Kersten
Currently I've added an error message to the attach context wizard if the task is not in a synchronized state. In addition I'm (breaking my own rule) forcing the task state to outgoing when attaching the context (in order to keep the in/out state in check). If attaching/retrieving context was integrated into the editor interface this sort of 'wierdness' wouldn't be necessary, it would become an intuitive part of the submission/synchronization process. Just like add self to cc is a check box, we could place another one there to attach the task context. UI could be added to the attachments section (and perhaps the comments section via context menu or hyperlink) for retrieving contexts. Thoughts? d'oh, just got a mid-air collision submitting this, here's what I was thinking. From a UI perspective, we could have a "Attach Context" check box on the Add Attachment wizard. If the user selects the "patch" checkbox, we could auto-select the "Attach Context" box. This makes it easy to upload the context with a patch but still gives the user control over whats happening. Both the Attach Context and Attachment wizards use the same upload mechanism, so we could upload the context after the attachment with no comment or an auto-gen comment (something like "Context for attachment XXX"), either that or add the upload context wizard pages to the attachment wizard if the "Attach Context" box is selected. The only thing I don't like about that is we would be asking the user for 2 comments, it could be confusing. Rob, our ideas seem to be pretty much in line with each other (except I suggested a check box in the wizard instead of the editor). Putting it in the editor might be a good idea so users can upload context with any type of submission (comment, etc..). We could still have the add attachment wizard auto-select the upload context check box if a patch is being attached. The only "issue" i see is that with the check box in the wizard, the user gets visual feedback about the context being uploaded when they select "patch" as their attachment type (the upload context box gets auto-selected). With the check box in the editor they might not notice it if it is auto selected, or might not remember to select it if its not. Actually it would be qute neat to attach such context to the report. More over, for Eclipse-related bugs context could be created from some historical data (if none activated), so it would give some hints how to reproduce errors, especially UI-related... But it seem a separate issue. :-) I guess the question here is, do we want to add support for uploading context along with a patch/attachment, or do we want to add support for uploading context along with any type of bug submission (attachment, comment, status change, etc...) ? Once that is answered we'll know how to structure the UI components (attachment wizard vs. editor) and the rest will follow from that. Any type of submission. If I do any kind of interaction (e.g. explore some code relevant to a comment) I may want to share that context with someone else. And what we'll get from the Focused UI before too long is better facilities for working with multiple contexts. The check box on the attachments section sounds like the best approach for now. We already auto-generate the description and could provide a one line text field for the 'comment' of the context attachment. Raising priority since this will save us all clicks. Sounds good, I'll get started on this one. Here's what I think would be simplest: make an "Add context to repository task" a checkbox that gets placed to the right of the "Add CC" checkbox under Actions. This will make the attachment process transparent, not require an additional comment, etc. It should be disabled if there is no context, and always be off by default since many comments will be made without the need to attach a context. I currently have the checkbox in the attachments section but it would make more sense in the actions section, I'll move it there. One issue I just noticed is that I can't upload the attachment fromt the BugzillaReportSubmitForm using the curent attachContext mechanism without making the bugzilla core depend on the tasks UI (attach context is part of AbstractRepositoryConnector). I figured it would be better just to submit the context after the report from the editor class rather than make that dependancy. Next week the AbstractRepositoryConnector will be split into a core and UI part, and the attachments will be core. So that will address this issue. But your work-around sounds good. 0.6.1 should be mostly freezing tonight and freezing tomorrow. Is this something you want in 0.6.1 or for the next release? I have a patch for this, I just need to write a test case before I post it. Everything works ok as far as manual testing is concerned though. Created attachment 46993 [details]
Attach context from editor
Adds a checkbox to attach context (below CC one, it didn't look right beside it)
-only enables if context exists
-auto-selected if a patch is attached
This is just the functionality sans test case you can have a look. I'll post a test as soon as it's done.
Created attachment 46994 [details]
mylar/context/zip
I don't think I'll have a test case ready in time for 0.6.1. The job that gets scheduled to run to upload the context doesn't run before the test case finishes (and thus fails). I'm not sure how to get around this. This feature basically just uses the existing mechanisms though, if the check box is selected it uploads the context using the existing functionality after commiting the initial changes to the report. Patch applied and manually verified. This UI streamlining will definitely make it easier for everyone to attach contexts. Our approach for testing those kinds of submissions is to have the test add a job change listener that it waits on. Is that doable? However, this is a pure UI change and we don't yet have UI tests for the editor itself, so before putting more time into it could you let me know what you're planning on testing? Assuming that the context attachment stuff is covered well enough by unit tests the way to test this would be to programatically press the check box, and then simply to check if the context attachment was requested (e.g. via the MockRepositoryConnector). >Assuming that the context attachment stuff is covered well enough by
>unit tests the way to test this would be to programatically press the check
>box, and then simply to check if the context attachment was requested (e.g. via
>the MockRepositoryConnector).
I was trying to this but with an actual bug submission. I'll look into using the MockRepositoryConnector.
Yes, we have a bunch of tests that use connectors in that way, but that makes them integration tests and not really unit tests. Mock tests of this sort are good because once you've got some infrastructure in place they become very easy to write and test very specific units of functionality, making them easy to debug. >Next week the AbstractRepositoryConnector will be split into a core and UI part
I can't access the MockRepositoryConnector from the bugzilla tests due to access rules. So, I'll just wait until the above refactoring is done so I can move the functionality from bugzilla to tasks and write the test there.
I updated the access rules so that bugzilla tests can now use the mock connector. However, this should not be a bugzilla-specific test, and so there is an underlying problem with the fact that we haven't finished generalizing the editor. Currently the driver for that will be Trac, so let's put off creating this test until we have more generic editor infrastructure in place (i.e. the tasks framework and tests should be responsible for making tests of this sort for you to write). If you already have something that you want to submit go ahead and do it and we can generalize it later, but I'm marking this task completed. Also noted that I added the icon to both the check-boxes in order to make them stand out more. Created attachment 47078 [details]
mylar/context/zip
|