Community
Participate
Working Groups
Most of the time there is only one context associated with a task. Selecting the "Retrieve Context" right-mouse menu item should retrieve it by default. If there are multiple contexts, "Retrieve Context" should display the normal Select Context dialog.
We display this dialog because we have no other way of displaying whose context the user is getting. So I'm not sure if this is worth streamlining away. To streamline retrieving contexts I'm thinking that we should make the actions more accessible within the task editor. Thoughts?
Hi Mik! Personally, I think context should be completely ambient. The user should never have to explicitly record, attach, retrieve context. It is always *on* for the active task. If the user doesn't want something in context, they can pause context collection and resume when they are back on task. If they make a mistake, they should be able to edit the context transcript/journal. Context from multiple users should be aggregated transparently. The user can always look at the transcript/journal to see who did what and when, or to filter context (e.g., only show *my* context or Mik's context, ignore Mr. Newbie). Also, every commit message in CVS that includes the task id should always also appear in context, even if the user didn't open the file via Mylar. Ideally, Mylar would even look at the methods/fields that were changed and automatically highlight them in context. Right now, there is disconnect between context and cvs change history.
I agree with Mark. There is probably not much value in displaying dialog with single entry after user confirmed that he want to retrieve context. What could be improved is that we can merge "yes/no" dialog and the context selection dialog into one, or at least show details for that single context in the confirmation dialog. But then, why not just fetch context without confirmation if you can?...
The benefit of the retrieve context dialog is that it shows the date and submitter of the task context. Also, we are likely to add additional facilities to the dialog that will require user input (e.g. bug 178883). So instead of streamlining retrieving contexts in this way, with 2.0M2 we addressed this use case by providing an action for retrieving that requires no user user input is now available on the Attachments table. *** This bug has been marked as a duplicate of bug 159318 ***
