It's all about the answers!

Ask a question

Can we share Streams and components from one project area into another project area into RTC.


Pankaj Kumar (177) | asked Jul 28 '17, 6:07 a.m.
retagged Aug 09 '17, 4:43 p.m. by Ken Tessier (84117)

I am using RTC 6.0.3. Recently I have started using SCM, so having following queries on same

1.  Can we share Streams and components from one project area into another project area into RTC. 


Please assist me on above queries.

Thanks in advance.

Regards,
Pankaj


Comments
Geoffrey Clemm commented Jul 29 '17, 5:20 a.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER

 Unless your questions are very closely related, please post them as separate questions, so that they can be of greater use to the community trying to look up an answer.  For example, questions 2 and 3 are closely related enough to be posted in one question, but all of the other questions should have been posted as separate questions.


Geoffrey Clemm commented Jul 29 '17, 5:24 a.m. | edited Jul 29 '17, 5:24 a.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER

  Here are the additional questions from the original post ... please post as separate questions:

2.  Is there any limitation in SCM that only some specific type of files we can checkin or any type of file we can checkin?
3. Is there any limitation on size of file? 
4. What is minimum level of permission we can give so user can just add a file?
5. A user having 'deliver' permission but once he is tryin to add one file through web client it's showing following error-"CRJAZ6053E The 'Deliver' operation cannot be completed. "Modify collections of process attachments" permission is required to complete the operation." 
After giving 'Modify collections of process attachments' also same error it is showing.
6. While checkin some file through web client we will having an option of associate workitem , we are associating an workitem but once will check the workitem's link section there will be no link created.
7. While associating workitem we can associate only existing workitem. Is there any option to create new workitem there itself and then associate.


Geoffrey Clemm commented Jul 29 '17, 5:27 a.m. | edited Jul 29 '17, 5:37 a.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER

 Here are Nate's original answers to the other questions ... please defer additional comments/answers on these other questions until they are posted as separate questions.


 Question 2: I'm not familiar with any restriction on file type. I can't imagine why there would be one.

Question 3: There is a file limitation out-of-the-box. I don't remember how big it is but I think it might be 500MB or something like that. In our 5.0.2 environment, we had users that were exceeding this limit (they were uploading disc images) and this actually caused the server to hang. So at least in 5.0.2, the server doesn't not handle this scenario gracefully. We addressed this by removing the file size limitation (since we couldn't dissuade the user from uploading disc images). I can't recall how to change that configuration so you'll have to look it up. I was reading the release notes for 6.0.4 recently and I think there is an operation behavior available in that version that can prevent file sizes from being uploaded based on their size. So that sounds like a more graceful way of restricting large deliveries.

Question 5: That sounds like a standard permissions issue and the error message is telling you exactly what permission is needed. That being said, it does sound like the permission the tool has identified shouldn't be required for the operation you are describing. Delivering files to source control shouldn't count as a modification of the project area's process attachments. I've never seen that error before myself, but it sounds like a bug. I think anyone who is using source control properly though so should be using a desktop client (eclipse or visual studio). That helps to ensure your delivery to a stream doesn't bypass your workspace that flows into that stream. I suppose you aren't obligated to keep your workspace and the stream synchronized, but it seems like a good idea. Of course you could deliver to your workspace instead of the stream, but it just seems easier to mess up than the eclipse client.

Question 7: You should be able to create the work item at the time you are prompted to associate it. I'm pretty sure I've done that before, but I would have to test to confirm. I think you can do it from the screen where you are prompoted to specify the associated work item. There should be a "Create Work Item" hyperlink in the bottom-left corner of that dialog.

3 answers



permanent link
Nate Decker (37812858) | answered Jul 28 '17, 8:41 a.m.
edited Jul 29 '17, 5:46 a.m. by Geoffrey Clemm (29.9k23035)
I guess this depends on what you mean by "share". You can set up your workspace so that it uses components from streams in different project areas. You can also change your flow target of your workspace to feed into different streams from different project areas (though I believe you can only do one flow target at any given time). you can make your workspace "public" so other people can load from your workspace so that's another way to sort of "share". At any given time, you can change the "Owned By" of a stream to a different project area so that seems like another way you could share it. You can also change the access for a particular project area so that the project is "public" and therefore any streams within that project area would be "shared" across all users who have access to the repository. So it seems like there are a lot of ways to do this.



permanent link
Geoffrey Clemm (29.9k23035) | answered Jul 29 '17, 5:46 a.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER

 I agree with Nate's answer above, but I'd phrase it slightly differently:

There are two quite different things you could mean by share: give read access, and give write access.
To modify what users have read access to a stream, open the stream in the Eclipse editor, and you can modify the Owned-By field and/or the Visibility of the stream to share the stream with a different set of users.
To modify what users have what kind of write access to a stream, you can modify the Owned-By field, and/or adjust both the Permissions and Operation Behavior Pre-Conditions for streams in the owning project area.


permanent link
Ken Tessier (84117) | answered Aug 09 '17, 4:42 p.m.

For information about delivering changes across repositories, see:



Ken

Your answer


Register or to post your answer.