Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 159166

Summary: Actions on working sets or several selected projects should gracefully ignore projects they cannot process
Product: [Eclipse Project] Platform Reporter: Philippe Ombredanne <pombredanne>
Component: TeamAssignee: Platform Team Inbox <platform-team-inbox>
Status: RESOLVED DUPLICATE QA Contact:
Severity: normal    
Priority: P3    
Version: 3.2   
Target Milestone: ---   
Hardware: PC   
OS: Windows XP   
Whiteboard:

Description Philippe Ombredanne CLA 2006-09-28 14:03:22 EDT
Some actions already handle that explicitely elsewhere in the platform.
For instance, if I select a working set, right click and select close, all the projects (closed or not) will be closed, the same applies to project clean.

The actions will still be performed, despite some projects are already closed.

Yet in team for many other common scenario, this fails very annoyingly, or the pop up are disabled.

The "failure" when the popups are enabled and I select a team action is that a dialog will come: "the chosen operation is not enabled"

Some examples:
When right clicking on a working set that contains shared and non-shared project, all the team popups will be disabled (most of the times, yet sometimes ther are enabled, but will not work)
If there is only shared projects in that set, yet one of the projects is closed, we have the same issue.
More annoying, if I filter out closed projects, then the popups will still be disabled.
In that case I can only resort to selecting each project manually, and I have to make sure that projects are shared.
That is a pain, and unproductive.

Therefore, I suggest to think about an enhancement by which enablement could be defined in a more flexible way for team actions, for instance so that it could optionally ignore resources that it is not interested in.

Typically non-shared projects and closed projets, if they exists either in the selection or the working set should be ignored when deciding about the enablement of the team/synchronizing.

This could be optionally driven by a preference set to default to the current behavior, to avoid suprising changes.
But I do not think that would be needed, and I think that most of us would eexpect things to work on the shared, non-closed projects, even if some projects are closed or non-shared.
Comment 1 Michael Valenta CLA 2006-10-02 14:01:36 EDT

*** This bug has been marked as a duplicate of 139775 ***