Scenario:
User A "check-in & deliver" a file and associates it with a work item using the Eclipse client.
User B accesses the work item using the Web client, browses the change set and received an error:

Error fetching change set: User 'B' does not have permission to read workspace 'A private Workspace' - Error code 403

Cause:
The URL of the change set points to user A's private workspace.
This explains the error.

Question:
How comes, that the work item is not linked to a change set in the team stream?

N.B.
User B can access the same work item using the Eclipse client, browse the change set and receives no error. The Eclipse Client is smart enough to access the Stream (or B's workspace).This sounds like a bug. Please open a work item about it against Source Control WebUI.

https://jazz.net/jazz/web/projects/Rational%20Team%20Concert#action=com.ibm.team.workitem.newWorkItem

I agree with Tim's recommendation to submit a bug report.

A change-set is a free-standing object, and does not belong to a
workspace or a stream, so that wouldn't be the cause of the problem.
If I had to guess, I'd say that the Web UI is using the "workspace hint"
that is associated with a change-set when it is linked to a work item
(this hint is used to help create a reasonable pathname to the files in
the change-set), and the Web UI is throwing this error when the
workspace is private, rather than doing what it should, which is to just
ignore the workspace hint in this case. But I'm just speculating here (:-).

Cheers,
Geoff

On 9/26/2011 4:53 PM, tmok wrote:

tgauwrote:
Scenario:
User A "check-in& deliver" a file and associates it
with a work item using the Eclipse
client.
User B accesses the work item using the
Web client, browses the change set and
received an error:

Error fetching change set: User 'B' does not have permission to read
workspace 'A private Workspace' - Error code 403

Cause:
The URL of the change set points to user A's private workspace.
This explains the error.

Question:
How comes, that the work item is not linked to a change set in the
team stream?

N.B.
User B can access the same work item using the
Eclipse client, browse the change set
and receives no error. The Eclipse Client is smart enough to access
the Stream (or B's workspace).

This sounds like a
bug. Please open a work item about it against Source Control WebUI.

https://jazz.net/jazz/web/projects/Rational%20Team%20Concert#action=com.ibm.team.workitem.newWorkItem

There are two different scenarios and here's why they work the way they do.

1. opening change set from links in work items.

This link was created from where the change set was created, it contains the workspace that originally contains the change set. in my test, it's (notice the bold workspaceItemId parameter):

https://ella.ottawa.ibm.com:9443/ccm/web/projects/JUnit%20Project%20-%200421#action=com.ibm.team.scm.viewChangeSet&workspaceItemId=_UfRN8OnmEeCWYo5IeI0dEQ&changeSetItemId=_AXiYwenoEeCWYo5IeI0dEQ&projectAreaItemId=_KhlVwGwDEeCSgq-6AuMh2g

So this link will try to open the change set in the context of the private workspace. If the user doesn't have the permission, he/she can't see it. A trick you can do is removing the workspaceItemId parameter, the change set without any context is accessible.

2. Opening the change set from an item history view in a stream.

If you go to the target stream from the web, browse to an item in the change set, open its History tab. And click "Open Full Change Set" link, the change set is accessible, because the change set is in the context of the public stream. In my test, this is:

https://ella.ottawa.ibm.com:9443/ccm/web/projects/JUnit%20Project%20-%200421#action=com.ibm.team.scm.viewChangeSet&contextItemId=_J1sDoGwEEeC07uOlpo8g2g&contextItemType=com.ibm.team.scm.Workspace&changeSetItemId=_AXiYwenoEeCWYo5IeI0dEQ

To answer the question:
> Question:
> How comes, that the work item is not linked to a change set in the team stream?

The change set is linked into the work item Before it's delivered to the team stream. At that point, the workspace is The only context for the change set. The web UI makes an effort to respect the context of change set and have it reflected in the breadcrumbs.

I agree with Tim's recommendation to submit a bug report.

A change-set is a free-standing object, and does not belong to a
workspace or a stream, so that wouldn't be the cause of the problem.
If I had to guess, I'd say that the Web UI is using the "workspace hint"
that is associated with a change-set when it is linked to a work item
(this hint is used to help create a reasonable pathname to the files in
the change-set), and the Web UI is throwing this error when the
workspace is private, rather than doing what it should, which is to just
ignore the workspace hint in this case. But I'm just speculating here (:-).

Cheers,
Geoff

On 9/26/2011 4:53 PM, tmok wrote:

tgauwrote:
Scenario:
User A "check-in& deliver" a file and associates it
with a work item using the Eclipse
client.
User B accesses the work item using the
Web client, browses the change set and
received an error:

Error fetching change set: User 'B' does not have permission to read
workspace 'A private Workspace' - Error code 403

Cause:
The URL of the change set points to user A's private workspace.
This explains the error.

Question:
How comes, that the work item is not linked to a change set in the
team stream?

N.B.
User B can access the same work item using the
Eclipse client, browse the change set
and receives no error. The Eclipse Client is smart enough to access
the Stream (or B's workspace).

This sounds like a
bug. Please open a work item about it against Source Control WebUI.

https://jazz.net/jazz/web/projects/Rational%20Team%20Concert#action=com.ibm.team.workitem.newWorkItem

The associated WI should be reverted from Enhancement back to Defect:
The breadcrumbs pointing back to the workspace are no longer relevant and should have been updated with a pointer to the public stream.

I've posted this request to the work item.
Note that the work item is still marked as planned-for 4.0, so hopefully
this means it will be fixed.

Cheers,
Geoff

On 1/5/2012 10:53 AM, generatz wrote:

The associated WI should be reverted from Enhancement back to Defect:
The breadcrumbs pointing back to the workspace are no longer relevant
and should have been updated with a pointer to the public stream.

Regardless of how the work item will be fixed and enhance the behavior, there is a simple workaround:

From the browser, simply remove the "&workspaceItemId=xxxxxxx" parameter in the URL and the change set can be accessed.

Bianca

I've posted this request to the work item.
Note that the work item is still marked as planned-for 4.0, so hopefully
this means it will be fixed.

Cheers,
Geoff

On 1/5/2012 10:53 AM, generatz wrote:

The associated WI should be reverted from Enhancement back to Defect:
The breadcrumbs pointing back to the workspace are no longer relevant
and should have been updated with a pointer to the public stream.

Thanks bjiang!