Bug 211467 - attach context in same comment, not different one
Summary: attach context in same comment, not different one
Status: ASSIGNED
Alias: None
Product: z_Archived
Classification: Eclipse Foundation
Component: Mylyn (show other bugs)
Version: unspecified   Edit
Hardware: All All
: P4 enhancement (vote)
Target Milestone: ---   Edit
Assignee: Project Inbox CLA
QA Contact:
URL:
Whiteboard:
Keywords: helpwanted
Depends on:
Blocks:
 
Reported: 2007-11-29 11:43 EST by Alex Blewitt CLA
Modified: 2011-09-28 02:25 EDT (History)
3 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Alex Blewitt CLA 2007-11-29 11:43:51 EST
When someone adds a mylyn context, it always shows up as a second comment. Is it possible to not do that, but instead add it and the comment at the same time? Otherwise every other comment is 'attached context'. It's possible to add a comment along with the attachment (and indeed, the comment says 'attached context') so why not use that in place of what the user has just typed?
Comment 1 Eugene Kuleshov CLA 2007-11-29 13:22:34 EST
Not to say that it can't be improved, but described scenario is probably specific to Bugzilla, other issue trackers, such as JIRA, don't support comments for submitting attachment.
Comment 2 Alex Blewitt CLA 2007-11-29 18:06:11 EST
OK, changing it to be bugzilla specific. In fact, it's more of a problem with bugzilla, because the attachment causes a further comment to be added.
Comment 3 Mik Kersten CLA 2007-12-05 22:28:44 EST
Yup, the multiple comments are a bit annoying.  Are you proposing that if "Attach Context" is checked off, the text in the "New Comment" will be used for the attachment comment instead?  It's a bit odd since the user might be expecting a separate comment to be generated instead of the one that's associated with the attachment, but I do wonder if it is a better compromise than the current behavior.  The alternative would be for us to render the context attachments differently, or to suppress rendering them alltogether.
Comment 4 Eugene Kuleshov CLA 2007-12-06 00:59:08 EST
Mik, it may go away all together if "add attachments" will work more like an editor action as opposed to RCP facade for bare http submission. Currently user can't create multiple attachments and then submit them at once, but have to go trough quite verbose wizard for each individual submission. Not to mention creating attachments offline and submitting them after getting back online.
Comment 5 Frank Becker CLA 2009-01-26 15:21:30 EST
What is with the configuration parameter set on for commenton... (see editparams.cgi?section=bugchange)
- commentonclearresolution
- commentonchange_resolution
- commentonreassignbycomponent
- commentonduplicate

For these it is impossible to set those fields when attach the content at the same time.
Comment 6 Mik Kersten CLA 2009-01-27 17:03:41 EST
Frank: If this is possible, you could take a look at it.  If not possible with Bugzilla 3.2, consider closing.
Comment 7 Frank Becker CLA 2009-01-28 14:45:28 EST
(In reply to comment #6)
> Frank: If this is possible, you could take a look at it.  If not possible with
> Bugzilla 3.2, consider closing.
> 

Yes I can implement this. But this will only work for installation where all following parameter have the status off

- commentonclearresolution
- commentonchange_resolution
- commentonreassignbycomponent
- commentonduplicate

Without a change in Bugzilla I see now way to get the state of parameters in the configuration. But I think that we need to be fast to get this into Bugzilla 3.4.

How should we continue?

I think the best is to plan for Bugzilla 3.6 and maybe try to switch to webservice and make sure that all Mylyn related things are included.

Thoughts?
Comment 8 Mik Kersten CLA 2009-02-06 10:53:16 EST
Given that it would be configuration-specific, I'm not sure this is worth it, especially since some of those parameters look like they might be on by default.

What if instead we improved the way attachments are rendered in the task editor?  For example, if a common only corresponds to an attachment, instead of the person icon we could use a file icon.  Later, a fancier UI could inline a thumbnail or preview of the file, e.g., using a Browser widget to render an attached image.  For context attachments, we could use a context icon, and instead of having the "Reply" drop-down on the comment's header, have a "Retrieve Context" action there.