Bugzilla – Full Text Bug Listing
| Summary: | Allow to submit attachments when task have local or incoming changes | ||
|---|---|---|---|
| Product: | z_Archived | Reporter: | Dmitri Maximovich <maxim> |
| Component: | Mylyn | Assignee: | Steffen Pingel <steffen.pingel> |
| Status: | RESOLVED FIXED | QA Contact: | |
| Severity: | normal | ||
| Priority: | P3 | CC: | robert.elves |
| Version: | 2.0 M2 | ||
| Target Milestone: | 3.0 | ||
| Hardware: | PC | ||
| OS: | Windows XP | ||
| Whiteboard: | |||
| Bug Depends on: | |||
| Bug Blocks: | 211072 | ||
|
Description
Dmitri Maximovich
Jira version: (Professional Edition, Version: 3.6.5-#161) Dmitri, can you check that you don't have outgoing changes on that editor and also clarify how did you invoke "attach context" action? PS: it seems like you won't be able to work with attachments on your JIRA server. Currently attachment retrieval is only supported for JIRA versions starting from 3.7 Eugene: could you please update the Known Limitations in the FAQ to list this as a version-specific limitation? Eugene, Indeed I was able to attach context to the Task (via 'Attach context' in task's pop up menu in task list) after I clicked 'Submit' button on the task, even so there were no apparent/intentional outgoing changes in the task. Now I can see attachment 'mylar-context.zip' in the Jira, but 'Retrieve Context' menu item for that task is still greyed out and there is nothing in the 'Attachments' section of the task window. Dmitri, there is "Mark / Clear outgoing" action in the task editor and Task List view popup menu that should allow to clear unintentional changes. There should be also an outgoing marker in the Task List view for that task if there are changes. As for context and attachment retrieval you'll need JIRA version 3.7 and later, because before that info about attachments hasn't been provided from the server. Rob, Mik, I wonder why do we actually need that check for outgoing changes when submitting attachments? It seem redundant and adds confusion. (In reply to comment #5) > Rob, Mik, I wonder why do we actually need that check for outgoing changes when > submitting attachments? It seem redundant and adds confusion. Submitting a file breaks the editors sync lifecycle (submission/dirty state/incomings etc.) this is a hack to avoid a) loss of edits, and b) false incoming notifications. Since edits are store separately now under the covers, we may be able to make this work more smoothly but it is tricky business. (In reply to comment #6) > Submitting a file breaks the editors sync lifecycle (submission/dirty > state/incomings etc.) this is a hack to avoid a) loss of edits, and b) false > incoming notifications. Since edits are store separately now under the covers, > we may be able to make this work more smoothly but it is tricky business. Hmm. I wonder if it can be somehow made non-tricky. Editor already capable to take incoming changes and update attachments and comments, so I am not sure what issues you referring to. The synchronization warning is particularly confusing when there are outgoing changes since synchronizing the issue does not help. Not to mention that the outgoing changes indicator is not visible when the issue is selected (at least on Linux). (In reply to comment #7) > Hmm. I wonder if it can be somehow made non-tricky. Editor already capable to > take incoming changes and update attachments and comments, so I am not sure what > issues you referring to. If you comment out the check for outgoing and test you will likely see some inconsistent behavior. That said, we should be able to work around this so either create a new bug or rename this one and assign to me and I'll look into it. (In reply to comment #8) > Not to mention that the > outgoing changes indicator is not visible when the issue is selected (at least > on Linux). Steffen, if you haven't already, post a bug as Mik will want to fix this Linux ui issue. (In reply to comment #9) > If you comment out the check for outgoing and test you will likely see some > inconsistent behavior. That said, we should be able to work around this so > either create a new bug or rename this one and assign to me and I'll look into > it. Here you are Fixed for JIRA as part of bug 222833. Attachments can now be submitted regardless of the synchronization state of tasks. Marking as resolved. |