It's all about the answers!

Ask a question
QuestionsTagsUsersBadges
Follow this question
Question details

×42,787
×11,924

question asked: Nov 16 '15, 4:25 p.m.
question was seen: 2,178 times
last updated: Nov 21 '15, 10:56 a.m.

Related questions

FAQ - How this Forum works

How to restrict users from delivering code in shared workspace

0
Pravin Patil (104●1●38●133) | asked Nov 16 '15, 4:25 p.m.
I have StreamA and StreamB > StreamB has shared componentA from StreamA. 
FileA.java is present in StreamA>ComponentA and StreamB>ComponentA. FileA.java gives me a conflict when I switch the flow target of StreamB to StreamA (changes of StreamA flowing into StreamB). Now I want to notify the developer about this conflict. So I share this workspace with developerA. He searched for this shared workspace and loads it on his pending changes.
But I dont want that he resolves the conflict in the workspace that I shared with him. Is there a way that he sees my shared workspace in readonly mode? This will help him see the conflicts and deliver corrected code, but he should deliver it from his workspace.

This is very vital since there are many files and many developers involved in my project with more then 13 streams and flow targets to be switched daily.

Please let me know.

Accepted answer

2
permanent link
Geoffrey Clemm (30.1k●3●30●35) | answered Nov 17 '15, 2:10 a.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER
A user cannot make changes to a repository workspace that is owned by another user.
Geoffrey Clemm selected this answer as the correct answer
Comments
Pravin Patil commented Nov 17 '15, 1:44 p.m.

  I did a scoped based sharing of my workspace (so my scope was the project area). Now other developer who is also a member of the project area, was able to modify and deliver a change set from the shared workspace. Am I missing something?

1
Geoffrey Clemm commented Nov 18 '15, 10:17 p.m. | edited Nov 21 '15, 10:56 a.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER

The scope of a workspace should only determines who can read a workspace, and should not affect who can modify a workspace.  If anyone other than an owner of a workspace can modify a workspace in your environment, please report this as a bug to IBM support.

One other answer

Most liked answers ↓|Newest answers|Oldest answers

0
permanent link
Hakki Bozkurt (163●12●28) | answered Nov 17 '15, 2:40 a.m.
Hi Pravin,

select a stream and right click
new ► repository workspace
give a name and type description (optional)
click next :)
select a repository (current or another)
click next :)
please read them carefully
select a scoped 

i think it is your wish.

Comments
1
Pravin Patil commented Nov 17 '15, 1:44 p.m.

 I did a scoped based sharing of my workspace (so my scope was the project area). Now other developer who is also a member of the project area, was able to modify and deliver a change set from the shared workspace. Am I missing something?

Hakki Bozkurt commented Nov 18 '15, 4:35 a.m.
Hi Pravin I think yes we missing something both. Your components have public read access. Our structure maybe help you for this issue..
1
Hakki Bozkurt commented Nov 18 '15, 4:35 a.m. | edited Nov 18 '15, 10:18 p.m.
Our Streams & components
Team A Streams (Visibility: Project Area, Owner: Team A)
X Comp (Visibility: Public, Owner: RTCADMIN)
Y Comp (Visibility: Public, Owner: RTCADMIN)
Team B Streams (Visibility: Project Area, Owner: Team B)
Z Comp (Visibility: Public, Owner: RTCADMIN)
T Comp (Visibility: Public, Owner: RTCADMIN)

Sample scenario 1: 
We have 2 developers same team for example Team A.

Developer 1: Create new repo. ws. from Team A Stream and load X component
Developer 2: do same thing like developer 1

Dev1 create a change set for example he change sample.txt and deliver.
Dev2 look up the your pending changes and see dev1's change set in incoming changes. He must accept it. And dev2 create new change set for sample.txt and deliver.
Dev1 see it and accept like dev2.

Sample scenario 2: 
Dev1 and Dev2 load same component and they working same time for same sample.txt.
Dev1 create his change set and deliver.
Dev2 create his change set and press deliver he have a warning from RTC SCM "This file have a conflict what are you doing bro?" 
Dev1 and Dev2 talks about that and they resolve confilct together. (people communication)

Sample scenario 3:
Dev1 and Dev2 load same comp. and they working same time for same sample.txt but different versions.
They deliver their change set another workspace (Dev3's WS). Dev3 role is versions manager or SCM admin or conflict expert or superman :) He resolve conflict or select a version or  merge and deliver server.
Usually Dev3 = Dev1 + Dev2 it looks like scenario 2 but What is the difference? Diff. is shared WS.

We usually do not prefer load someone else's workspace. We prefer another workspace (shared ws). And we deliver server after resolving the problems.
Pravin Patil commented Nov 20 '15, 1:14 p.m.

 Thanks a lot for the details. This helps!

Your answer

Register or to post your answer.


Dashboards and work items are no longer publicly available, so some links may be invalid. We now provide similar information through other means. Learn more here.